AO-AIOO  603  AXR  FORCE  INST  OF  TECH  IIRt6HT«PATTERS0N  AFB  OH  SCHOO— ETC  F/6  9/2 
A  GENERALIZED  EXPERIMENT  CONTROL  AND  DATA  ACOUISXTION  SYSTEM. (U) 

MAR  61  A  R  ILORETA 

UNCLASSIFIED  AFIT/6CS/EE/81M-3  NL 


AF1T/QCS/IE/81M-3 


(a 

I  I  ^NERALIZED 

EXPERIMEMT  JCWTROL  AND  PATA ^^OJUISITICN  ^TEM* 


7 


THESIS,  i 

V  ( 


AFIT/g::S/EE/8^-3  j  Arsenic  R.  /Iloreta  j 

capearn — ^ — 'USAF 

// 


‘'i  //Joy  F/ 

/  > 


T'=-  V  ■ 

^  ?  t. 


nSi 


LJ 


Approved  for  public  release;  distribution  unlimited. 


•%  'cr- 


.7 


MTr/(ES/aE/8lM-3 


A  CZMER;\LIZ£D 

EXPERIME^TT  OQNTRX  AND  DATA  ACQUISITION  SYSTEM 


THESIS 


Preseited  to  the  Faculty  of  the  School  of  ESngineering 
of  the  Air  Force  Institute  of  Technology 
Air  University 

in  Partial  Fulfillment  of  the 
Requirements  for  the  Degree  of 
Master  of  Science 


by 

Arsenio  R.  Iloreta 
Captain  USAF 

Graduate  Ccnputer  Systems 
March  1981 


Approved  for  public  release;  distribution  unlindted 


Preface 


The  Materials  Laboratory  of  the  Mr  Force  Wright  Aeronautical 
Laboratories  (AEWAL/ML) ,  Wright-Patterson  Mr  Force  Base,  Otiio  performs 
a  nyriad  of  esqper  intents  in  which  a  great  amount  of  data  is  being 
gathered.  In  some  of  these  experiments,  data  gathering  still  involves 
manual  interaction  and/or  the  use  of  strip  chart  recordings  or  paper 
tapes.  Digitizing  the  strip  charts  so  that  further  manipulations  of  the 
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data  can  be  performed  is  laborious  and  prone  to  errors.  To  automate  the 
data  collection  for  a  wide  ra^e  of  experiments,  the  Materials 
Laboratory  purchased  the  necessary  i^dwcure  ocnponents.  It  was  about 
the  time  when  cLLl  the  ocnponents  vere  received  that  I  was  assigned  to 
the  Conputer  Activities  Group,  which- oversees  the  data  automation  needs 
of  the  Laboratory.  I  was  assigned  the  project,  and  subsequently  turned 
it  into  a  thesis  tqpic. 

I  wish  to  thank  my  si^rvisor  and  ny  Laboratory  sponsor,  Cept 
William  H.  Walker  TV,  for  letting  me,  in  fact  encouraging  me,  to  work 
on  the  project  with  a  view  towards  writing  it  as  a  thesis.  Acting  as 
the  critical  user,  he  also  provided  helpful  information  when  I  needed  it 
most,  fecial  thanks  goes  to  Colonel  James  P.  Etitledge,  my  advisor  and 
software  engineering  tutor,  for  his  technical  advice  and  direction;  to 
the  other  members  of  the  thesis  committee.  Major  Alan  Ross  and  Professor 
Thomas  Hartrum,  for  their  most  welcome  critique  and  ocnments;  to  Dane 
Banby  and  Frank  Beitel  of  the  University  of  Dayton  Research  Institute, 
for  providing  assistance  when  seemingly  trivial  hardware  and  softweure 
matters  escape  me;  and  to  AlC  Chung  Kong,  for  the  "nuts  and  bolts” 
operation  of  the  system.  Most  importantly,  I  wish  to  thank  my  wife, 
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Oai^;  our  diildren,  Joan  and  Demis;  ny  in-laws r  Jack  and  Lydia 
YacaSr  without  whose  love,  patience,  understanding,  si;(3port  and 
encouragement,  my  efforts  would  surely  have  come  ip  short  and  this 
project  would  not  have  come  to  fruition. 
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Abstract 


A  portable,  automated,  generalized  e^^riment  control  and  data 
acquisition  system  was  developed  for  the  Materials  Laboratory  to  fulfill 
some  of  its  data  automation  needs.  The  ^stem  is  portable  in  that  all 
hcurdware  conponents  fit  in  an  aluminum  carrying  case,  exc^t  for  the 
terminal  which  is  sepairate.  Tbe  need  for  portability  requires  the 
program  to  be  loaded  from  the  terminal  minicassette  t^>e.  The  collected 
data  is  likewise  dunped  into  the  minicassette. 

The  hardware  oonponents  were  already  procured  before  actual 
softwcire  development  was  begun,  which  included  an  extensive  software 
requirements  definition  phase.  The  Air  Force  method  of  requirenents 
definition,  IDEIPO,  was  used  to  model  the  software  requirsnents.  It 
involves  a  top-down  ^proach  to  development.  The  model,  thus 
diagrammed,  pro'/ided  the  general  structure  from  which  the  program  itself 
was  written.  Structured  code  and  anple  documentation  form  the  basic 
programming  technique  inplemented.  The  program  is  currently 
operational,  the  system  having  been  utilized  in  two  actual  experiment 
set-ips.  The  requirement  to  load  the  program  from  the  minicassette  was 
not  satisfied,  however,  because  of  some  loader  error.  The  program  can 
presently  be  loaded  using  a  floppy  disk  system. 
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I.  Introduction 


Background 

Itie  Materials  Laboratory  of  the  Air  Force  Wright  Aeronautical 
Laboratories  (AFWAL/ML) ,  Wright-Patterson  Air  Foroe  Base,  Ohio,  performs 
a  variety  of  e3?)er iroents  aimed  at  understanding  the  properties  of 
materials.  These  ej?)eriments  can  be  categorized  into  two  basic  _->es: 
(1)  those  that  have  dedicated,  automated  data  acquisition  systems 
designed  (built)  into  them,  and  (2)  those  where  data  is  gathered  by 
manual  observaticxi  and  measurement  or  by  using  strip  chart  recorders. 
Both  t^pes  of  experiments  have  their  limitations.  De^ite  great  strides 
in  the  reliability  of  automated  data  acquisition  systems,  these  systems 
occasionally  fail.  Depending  on  the  severity  of  the  breakdown,  it  could 
take  some  time  before  the  eiqjeriment  can  be  continued  or  started  again. 

Data  collection  by  manual  observation  and  measurement  is  tedious 
and  inherently  inaccurate.  Likewise,  the  use  of  strip  charts  can  be  as 
inaccurate  if  human  interaction  is  required  to  read  data  off  the  charts 
(digitize)  for  further  processing  in  order  to  determine  the  material 
property  of  interest.  For  instance,  areas  under  strip  chart  curves  are 
usually  of  high  interest  and  must  be  manually  determined. 

The  benefits  of  automating  the  data  acquisition  process  for 
eiqperiments  requiring  manual  interaction  are  obvious  (with  due  regard  to 
the  reliability  problem  mentioned  above) .  This  will  not  only  free  the 
experimenter  to  do  other  tasks  but  will  also  increase  the  speed  and 
accuracy  of  the  process.  Hcwever,  since  experiments  requiring  manual 


interactican  are  normally  very  highly  specialized  and  are  short-term  or 
one-time  in  nature,  the  cost  of  procuring  an  automated  system  for  each 
experiment  is  enormous.  A  portable,  general,  automated  data  acquisition 
system  is  therefore  required.  This  general  system  can  also  serve  cis  a 
back-Lp  system  to  eiperiments  of  type  (1) . 

Ihe  portable  data  acquisition  system  can  additionally  be  used  as  an 
experiment  controller,  albeit  a  very  primitive  one  indeed.  By 
monitoring  the  values  of  a  certain  ^>ecified  measurement,  an  appropriate 
predetermined  acticxi  can  be  taken  vrtien  these  values  get  out  of  a  given 
rcinge.  This  action  can  be  a  message  to  the  operator  or  it  can  be  an 
automatic  adjustment  of  an  experiment  parameter  that  the  automated 
system  controls. 

It  is  not  usually  sufficient  to  proceed  directly  into  designing  a 
hardware  and/or  a  software  solution  as  soon  as  a  need  for  an  automated 
system  is  identified.  Nor  can  the  hardware  and  software  efforts  be 
totally  removed  from  one  another.  Whereas  hardware  considerations  may 
sinply  involve  purchasing  off-the-shelf  equipments,  software  development 
involves  more  than  sinply  designing  the  algorithm  and  then  coding  it  in 
a  suitable  programming  language.  Too  many  software  projects  have 
encountered  enormous  cost  and  time  overruns  because  the  software 
requirements  were  never  really  defined.  In  fact,  software  costs  have 
become  a  sizable  portion  of  the  Air  Force's  budget  (Ref  10:12) . 

Hie  Air  Force,  through  numerous  reviews  and  ^lecification 
requirements,  has  begun  to  address  the  many  phases  of  software 
development.  These  phases  include  syston  requirements  definition. 
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test  and 


software  requiranents  definiticxi,  design,  code  and  debug, 
integraticxi,  aind  operations  and  maintenance  (Ref  2:1226-1227).  Still, 
projects  with  varying  degrees  of  dif fk  ulty  meeting  schedule  and  budget 
constraints  are  very  frequently  identified.  Studies  made  of  these 
projects  have  shown  that  they  are  lacking  in  the  requirements 
definitions  phase  of  the  development  (Ref  10) .  Requirements  definition 
is  the  process  of  specifying  what  probl^  is  to  be  solved.  Obviously, 
without  a  clear  understanding  of  vrfiat  the  system  is  to  perform,  the 
chances  of  something  going  wrong  are  increased  tranendously.  Inoonplete 
or  erroneous  solution  to  a  muddled  requirement  or  correct  solution  to 
the  wrong  problem  are  the  usual  results. 

Statement  of  the  Problgn 


TBie  purpose  of  this  study  is  to  develop  the  software  required  to 
implement  the  portable,  automated,  generalized  e^qjeriment  control  and 
data  acquisition  system. 

Constraints/Assunptions 

Although  the  software  to  be  developed  must  be  applicable  to  most  of 
the  Laboratory's  data  acquisition  needs,  the  Materials  Laboratory  has 
requested  that  the  software  be  initially  tailored  for  four  of  its 
projects,  namely:  (1)  laser  effect  testing,  (2)  polymer  cure  kinetics, 
(3)  liquid  chromatography,  and  (4)  mechanical  testing.  (See  Ch^ter 
III,  for  further  discussioi  on  these  projects.)  This  will  limit  the 
number  of  users  from  which  irput  data  to  the  software  requirements 
process  mist  be  gathered.  This  is  inportant  because  there  mist  be 
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ocmnon  agreement  among  parties  on  the  set  of  specifications  to  be 
developed. 


In  addition,  AEVJAL/ML  has  ailready  procured  an  151-11  microconputer 
system  and  associated  instrumentation  to  inplement  the  hcurdware 
requirements.  This  constitutes  an  additional  constraint  because  the 
software  to  be  developed  must  be  oonpatible  with  this  microconputer 
system. 

Approach 

The  software  requirements  definition  for  the  portable,  automated 
g&ieralized  experiment  control  and  data  acquisition  system  are  generated 
using  the  initial  version  of  the  Integrated  Conputer -Aided  Manufacturing 
(ICAM)  Definition  Method  (IDEFO) ,  developed  for  the  Air  Force  by 
SofTech,  Inc.  This  technique,  which  is  the  Air  Force  version  of  the 
Structured  Analysis  and  Design  Techniques  (SAOT) ,  involves  modeling  a 
system  by  means  of  a  oollectioi  of  diagrams  showing  things  (objects  or 
information)  and  activities  (performed  by  men  or  machines) .  The  model 
distinguishes  what  functions  the  systen  must  perform  from  how  the  system 
is  built  to  accorplish  those  functions  (Ref  5) . 

The  design  of  the  software  generally  follows  the 
oonposite/structured  design  techniques  advanced  hy  Myers  in  reference  9. 
Where  deemed  necessary,  deviations  are  made  and  duly  noted,  giving 
^ecific  reasons  for  such  deviations.  The  code  and  debug,  test  and 
integration,  and  operations  and  maintenance  phases  of  the  development 
are  in  accordance  with  prevailing  Department  of  Defense  and/or  Air  Force 


standards f  including  documentation  standards,  on  a  lot  smaller  scede 
(Itef  3) . 

Plan  of  Development 

Hie  requirenents  definition  for  the  portcible  data  acquisition 
systan  is  presented  in  Ch^ter  II.  The  software  requiranents  definition 
with  aiphasis  on  the  functional  ^>ecifications  is  discussed  in  Qiapter 
III.  Q]^ter  IV  presents  the  formal  functional  specifications  for  the 
system.  These  specifications  sure  in  the  form  of  activity  and  data 
models.  Design  of  the  software  is  the  topic  of  Qiapter  V  and  the 
remaining  develoE»nent  phases  are  included  in  Chapter  VI  .  Chapter  VII 
contains  the  summary  and  recommendations,  A  typical  porticxi  of  the 
code,  with  emphasis  on  the  documentation,  a  users  manual  and  a  printout 
of  a  sample  session  at  the  portable  terminal  are  placed  in  the  i^ppendix 
section. 
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II.  System  Reguireroents  Definitic»i 


Introduction 

Requirements  definition  enccnpasses  all  adjects  of  system 
development  prior  to  actual  ^stem  design /  everything  necessary  to  lay 
the  groundvork  for  subsequent  stages  in  system  development.  It  deals 
with  three  subjects:  1)  ocmtext  analysis,  which  deals  with  the  reasons 
wty  the  system  is  to  be  created;  2)  functional  ^)ecification,  which  is 
a  description  of  what  the  system  is  to  be,  in  terms  of  the  fu/ictions  it 
must  acootrplish;  and  3)  design  constraints,  which  includes  a  sunmary  of 
conditions  pacifying  how  the  required  system  is  to  be  constructed  and 
inplemented  (Ref  14:1-2).  For  this  study,  context  analysis  was 
discussed  in  Chapter  I;  functional  ^)ecification  is  presented  in  a 
later  section  of  this  chapter,  following  the  discussion  of  the  design 
constraints. 

Design  Constraints 

In  carder  to  take  advantage  of  the  Laboratory  esqsertise  on  Digital 
Equipment  Corporation  (DEC)  LSI-11  systems,  the  Materials  Laboratory 
chose  to  base  the  portable,  data  acquisition  system  on  the  LSI-11/2 
microprocessor.  Hie  other  hardware  oonponents  must,  of  course,  be 
cxxipatible  with  this  microprocessor.  A  block  diagram  of  the  portable 
system  is  shown  in  Figure  1.  Hie  major  conponent  parts  include,  in 
addition  to  the  ISI-11/2  microprocessor,  a  digital-to-analog  and 
analog-to-digital  converter  (ADAC  1030) ,  a  multiplexer/anplifier  board, 
a  clock  board,  and  the  cperator^s  terminal  (Miniterm  1205).  A  oonplete 
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parts  listing  for  the  systan  is  given  in  Table  I. 


Table  I.  Portable  Data  Acquisition  System  Ccnponents 


Paurt/PescriptiCTi 

IBI-11/2  Central  Processing  Unit 

32K  RAM  Memory 

BeK:i^lane/Card  Guide  Assembly 
Power  Sc^ly 
A/D  and  D/A  Converter 
P2u:allel  I/O  Port 
Serial  I/O  Port 
Floating  Point  Chip 
Poi:t2ible  Terminal 
Multiplexer 

Instrvmentation  Anplifier 
DC/DC  Converter 
Carrying  Case 
Clock  Board 


Manufacturer 

Part  Number 

DEC 

KDll-HA 

DEC 

MSVll-DD 

MEB  ^sterns 

MLSI-BPA84 

Standcurd  Power  Inc. 

SPS  130D  5/12 

ADAC  Corporation 

ADAC  1030 

DEC 

DFR/11 

DEC 

DLVll 

EEC 

KBVll 

Ccrputer  Devices 

Mini term  1205 

Harris 

HI3-0506-5 

Ancdog  Devices 

605K-100 

Analog  Devices 

940 

Zero  Corporation 

110-P6 
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ISI-11/2.  The  central  processor  for  the  portable  data  acquisition 
i^steiR  is  DECT’s  LSI- 11/2  (part  number  KDll-HA) .  It  is  a  microprocessor 
with  reasonably  fast  speed  and  has  32K  words  (16  bits)  of  meniory.  It 
supports  the  basic  PDP-11  instruction  set  and,  with  the  optional 
Floating  Instruction  Set  (KEVll)  (which  wcis  also  purchased) ,  can  perform 
floating  point  arithmetic  operations. 

ADftC  1030.  The  ADAC  1030  is  a  16-channel  analog-to-digital  plus  an 
additional  two-channel  digital-to-analog  converter.  It  is  configured  to 
have  fully  differential  analog  inputs  with  a  range  of  -10  volts  to  +10 
volts.  This  configuration  is  junper  selectable  and  was  chosen  to 
acocmnodate  the  more  common  range  of  analog  output  signals  found  in 
laboratory  devices.  The  weaker  signals  (millivolt  range)  are  anplified 
before  they  are  fed  to  the  converter.  Likewise,  the  selected  output 
remge  of  the  digital-to-analog  converter  is  -10  volts  to  +10  volts. 
Selection  is  also  through  the  use  of  junper  wires. 

Multiplexer/Anplifier.  The  multiplexer /anplifier  is  conprised  of  a 
multiplexer,  an  instrumentation  anplifier,  and  a  DC/DC  converter.  The 
particulett  circuit  that  is  used  in  this  project  was  designed  and  built 
by  Dane  Hanby  of  the  University  of  Dayton  Research  Institute  and  is 
shown  in  Figure  2.  The  output  of  this  circuit  is  fed  directly  to  the 
ADAC  A/1)  converter,  using  the  input  pins  for  channel  1  as  shown  in 
Figure  3. 

Clock  Board.  The  clock  board  provides  the  timing  interrupt  circuitry 
for  the  systan.  It  consists  of  a  crystal  oscillator  with  TTL  output, 
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Figure  2.  Multiplexer/Amplifier  Circuit  Diagram 


three  s^nichronous  decade  counters,  and  a  line  driver.  Hie  diagram 
(Figure  4)  shcxirs  the  interconnections  amcafig  the  circuit  parts  as  well  as 
the  interface  to  the  systOT.  This  circuit  was  designed  by  Tan  Wood 
while  he  was  working  for  the  University  of  Dayton  Research  Institute. 

Miniterm  1205.  This  is  the  portable  terminal  that  allows  operator 
comnunication  with  the  microocrputer  system.  It  provides  for  Standard 
RS232  interfacing,  has  a  built-in  acoustic  coupler  capable  of  300  or 
1200  baud  transmission  rates,  and  includes  8K  of  RAM  memory  (expandable 
to  32K)  making  it  possible  bo  edit  data  off-line  perhaps  after  or  in 
between  eiqieriments.  It  also  includes  a  minicassette  tape  drive  to 
provide  extra  storage  of  ^lecial  programs  or  historical  eiqperiment  data 
of  up  to  68,000  characters  per  minicassette. 

The  entire  hardware  of  the  system  is  contained  in  a  single  carrying 
case.  The  .  cperator^’s  portable  terminal  is  s^arate  and  is 
self-contained.  Set-up  requires; 

a)  connecting  power  cord  to  110  VAC; 

b)  connecting  cable  between  the  portable  terminal  and  the 
hcurdware  case; 

c)  wiring  analog  in/analog  out  experiment  lines  to  proper 
terminals  on  terminal  strip  of  hardware  case; 

d)  for  connection  to  the  remote  host  oonputer,  establishing 
ccmnunication  line  and  placing  telephone  receiver  in 
acoustic  coupler  receptacle. 
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Figure  4.  Timing  Interrupt  Circuit 


Functicmal  Specifications 

As  menticxied  in  Chapter  I,  the  Materials  Laboratory's  objective  is 
to  assenible  a  general,  portable  data  acquisition  and  experiment  control 
system  to  support  missicxi  essential  part-time  and  short-term  projects. 
This  ^stem  is  to  operate  in  two  basic  modes:  1)  data 
acquisitioiV’process  control  mode,  and  2)  data  ocmmunication  mode. 

In  the  data  ckcquisition/^rocess  control  mode,  the  syston  is  wired 
to  the  experiment  and  the  proper  data  acquisition  and  control  program  is 
loaded  from  the  operator  terminal's  cassette  tape.  Program  parameters 
are  set  by  the  user  from  the  terminal  keyboard.  Control  of  the 
ejperiment  is  initiated  and  data  acquisition  is  started.  After  data 
collection  is  oonpleted,  data  is  transferred  from  systeti  memory  to 
cassette  tape  and/or  to  the  a^Jrapriate  host  ocrputer  as  explained  in 
the  data  oonmunication  mode. 

In  the  data  oommunication  mode,  the  user  transmits  data  stored  in 
memory  or  cassette  tape  from  the  Mini  term  to  the  conputer  vrtiich  will 
perform  data  reduction  and/or  provide  long-term  storage.  This  mode  is 
cilso  used  to  transfer  the  absolute  code  for  programs  from  the  PDP-11/03 
development  system  to  the  portable  system  (cassette  t^>e)  or  programs 
from  cassette  tape  to  matrary. 

Software  development  was  performed  on  the  PDP-11/03  development 
system  and  transferred  to  cassette  tape  for  portability.  Note  that 
initial  program  checkout  may  be  performed  at  the  development  system 
site,  with  all  the  q^stem  interfaces  actually  available. 
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Sunnarv 


This  chapter  covered  the  functional  specification  and  design 
constraint  aspects  of  system  requirements  definition.  The  context 
analysis,  it  was  mentioned,  has  already  been  discussed  in  Ch^ter  I. 
The  rest  of  the  thesis  will  now  focus  on  the  software  development  for 
the  general,  portable  data  acquisition  system. 
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III.  Software  Raguironents  Definition 


Introduction 


Neglect  of  the  requirements  definition  phase  has  been  blamed,  along 
with  other  causes,  for  excessive  cost  and  schedule  overruns.  In 
addition,  the  elimination  of  this  inportant  st^  often  results  in  an 
inooitplete  documentaticxi  package  v^ich,  in  turn,  contributes 
significantly  to  cperations/maintenance  problems  later  in  the  software 
life-cycle. 

The  software  for  this  thesis  was  generated  to  inplement  the 
portable  data  acquisition  system,  the  hardware  conponent  parts  of  which 
have  already  been  procured  by  the  ^xjnsoring  laboratory.  The 
procurement  of  the  hardware  oonponents  represents  a  software  design 
constraint  inasmuch  as  the  software  product  must  be  conpatible  with  the 
procured  hardware  system.  Also,  while  there  are  numerous  packaged 
routines  available  for  such  systems  (I5I-11  systems) ,  the  portability 
requirement  represents  an  additional  design  constraint,  because  not  all 
these  routines  eire  usable  for  stand-alone  systans.  This  ch^ter 
describes  the  context  analysis  and  the  functional  ^ecification  aspects 
of  the  software  requirements  definition. 

Context  Analysis 


The  softwcire  requirement  is  for  the  iirplementation  of  the  portable 
data  acquisition  system.  Four  Materials  Laboratory  projects  were 
initially  identified  as  possible  applications  for  this  system.  These 


2ure  1)  laser  effect  testing,  2)  polymer  cure  kinetics,  3)  liquid 
chromatography,  and  4)  mechanical  testing.  In  order  to  develop  a  set  of 
softwcure  requirements,  we  mast  examine  the  individual  requirements  of 
these  four  exanple  projects. 

Laser  Effect  Testing.  This  e}?)eriment  determines  the  thermal  effects  of 
firing  a  laser  beam  at  a  given  material  i^jecimen.  Several  thermocouple 
beads  are  positioned  in  a  sanple  to  record  the  temperature  profile  of 
the  material  as  it  is  burned.  Presently,  the  signals  from  the 
thermocouple  wires  are  recorded  on  a  VISICDRDEK  chart.  In  order  to 
perform  mathematical  manipulations  of  the  collected  data,  the  charts 
must  be  digiti2ed.  At  most  ten  signals  are  monitored  for  each 
ejperiment  run.  The  run  itself  takes  ^roximately  ten  seconds,  with 
the  laser  beam  normally  on  for  only  0.3  second. 

Ihere  is  a  short  period  after  the  run  is  started  that  no  meaningful 
data  is  available  for  collection.  The  start  of  the  data  collection 
process  thus  requires  the  detection  of  a  SIART  signal,  which  is  not 
presently  available.  One  hundred  data  points  per  thermocouple  wire  meet 
the  digitizing  requirement;  which  means  approximately  one  thousand  data 
points  rrust  be  recorded  every  ten  seconds. 

Polymer  Cure  Kinetics.  The  Polymer  Branch  performs  polymer  cure 
kinetics  using  thermal  analysis  instrumentation.  A  polymer  sanple  is 
heated  at  a  given  rate  and  the  temperature  of  the  cell  in  which  it  is 
placed  is  recorded  at  specific  time  intervals,  usually  on  the  order  of 
one  second.  Presently,  this  tenperature  data  is  recorded  on  p^>er  t^Je 
and,  for  back-up  and  further  oonparison,  on  a  strip  chart.  For  further 


17 


data  manipulations/  the  paper  tape  is  read  into  the  host  oonputer  where 
the  necessary  application  programs  are  installed.  Itie  data  is  plotted; 
the  area  under  the  curve  is  determined;  amd  after  a  series  of  curves,  a 
time-tenperature-degree-of-cure  relationship  is  established  for  the 
polymer. 

Five  different  heating  rates  are  used  in  this  experiment  (80,  40, 
20,  10,  cux3  5  degrees  Kelvin  per  minute)  to  get  to  a  cell  tenperature  of 
400  degrees  Kelvin.  Between  350  and  500  tenperature  readings  are 
collected  per  scan  which  means  that,  for  the  shortest  experiment  scan 
(five  minutes) ,  at  most  one  hundred  of  these  readings  are  recorded  per 
minute. 

Liquid  Chromatography.  High  performance  liquid  chromatography  is  used 
in  the  Materials  Leiboratory  for  research  and  routine  quantitative 
analyses.  A  strip  chart  recording  is  the  output  medium  used  for 
collected  data.  Reading  the  charts  and  manually  determining  the  area 
under  each  "peak"  in  the  curve  (extrapolated  accordingly  if  peaks 
overlap)  is  the  standard  manner  in  vrtiich  the  relative  amount  of  each 
sanple's  ootiponents  is  measured.  A  normal  run  takes  approximately  two 
minutes  and  200  data  points  render  satisfactory  results. 

Mechanical  Testing.  The  Metals  Behavior  Branch  performs  experiments  to 
study  the  effect  of  cracks  on  strength  of  materials.  Sanples  are 
pl2K:ed  in  a  loading  frame  in  which  a  variable  load  can  be  exerted  on  the 
sanple.  Ihe  samples  are  notched  or  cut  perpendicular  to  the  axis  of 
loading  to  promote  cracking.  Ihe  rate  of  crack  propagation  is 
determined  in  part  by  the  amplitude  of  the  load  being  applied.  These 
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e3f>eciinents  sanetimes  take  an  inordinate  cimount  of  time  because  the 
cracks  do  not  propagate  very  fast;  or,  conversely,  end  abri^Jtly  because 
the  sanples  fracture  easily  with  the  applied  load. 

A  typical  crack  growth  e;q)eriment  usually  takes  between  eight  hours 
to  almost  three  weeks.  IV^nty  blocks  of  crack  growth  data, 
oorre^)onding  to  twenty  different  tenperatures,  are  gathered.  Each 
block  contains  50  to  150  data  points.  These  data  points  are  a  function 
of  the  ^eciroen  geometry,  the  applied  load,  crack  length,  and  time.  Ihe 
relationship  between  these  factors  is  predetermined  and  must  be 
maintained  through  the  experiment  run.  Since  the  specimen  geometry 
remains  essentially  constant,  the  applied  load  must  be  "controlled" 
according  to  the  rate  of  crack  propagation  (change  in  crack  length  over 
time) .  This  control  requirement  is  normally  performed  at  one-  to 
ten-minute  intervals. 

Because  of  the  time  element  involved  and  the  inherent  inaccuracies 
of  the  manucil  process,  the  need  is  clear  for  an  automated  systen. 
Automating  each  experiment'’ s  data  collection  process  according  to  its 
individual  requironents  is  economically  unfeasible.  Therefore,  emy 
automated  system  to  be  developed  must  be  general  enough  to  acccmroodate 
at  least  the  range  of  experiments  discussed  above.  It  must  aLLso  be 
portable  if  it  is  bo  be  easily  moved  from  one  experiment  locatic»i  to 
another. 

Projects  similar  to  those  mentioned  above  abound  in  the  Laboratory 
and  can  be  easily  adapted  to  utilize  a  portable,  automated  data 
acquisition  system.  In  addition,  the  dynamic  nature  of  the  Laboratory's 
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ocnnitment  to  materials  tesecirch  makes  it  very  desirable  to  build  such  a 
general  systan. 

Functional  Specifications 

Any  system  developed  mast  be  a  general-application  system.  It  mast 
provide  Oie  user  the  opportunity  to  define  his  particular  esperiment's 
data  collection  and  experiment  oontrol  needs.  Hie  oapability  to  record 
data  at  any  given  time  is  needed  in  the  system.  In  addition,  there  is  a 
need,  as  in  the  laser  experiment,  to  provide  a  mechanism  to  start  data 
collection  sepairately  from  the  stairt  of  the  experiment;  that  is,  to 
take  acticxi  depending  ipon  a  given  condition.  Hie  mechanical  testing 
experiment  exhibits  another  sort  of  need;  the  ability  to  provide 
feedback  to  the  experiment  to  oontrol  a  particular  parameter.  Hiese 
needs  make  ip  the  functional  specifications  discussed  below. 

Define  Experiment.  When  the  systen  is  first  put  into  cperaticai,  a  menu 
of  all  the  valid  commands,  including  their  descriptions,  is  shown  to  the 
user.  Among  these  is  a  DEFINE  oomnand  that  allows  the  user  to  define 
the  data  channels  he  will  use  in  oollecting  data  from  his  experiment. 
Hiis  oomroand  is  appropriately  labelled  as  the  first  oommcind  given  in 
nomal  system  operation.  Up  to  three  channel  files  can  be  defined: 
channel  schedule  file,  channel  dependency  file,  and  channel  oontrol 
file.  A  channel  schedule  file  mast  always  be  defined;  the  other  two 
are  defined  only  as  required. 

Hie  channel  schedule  file  consists,  as  a  minimum,  of  the 
information  required  to  collect  data  at  seme  indicated  times.  Hiis 
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information  may  include  the  initial  read  time  and  the  time  interval 
between  reads  for  each  channel  defined.  Hie  channel  dependency  file,  on 
the  other  hand,  is  defined  for  e^qieriments  where  certain  information 
does  not  become  meaningful  until  some  condition  curises;  for  exanple,  a 
voltage  reading  in  an  e)q)eriment  may  be  meaningless  unless  the 
tenperature  reading  in  cheinnel  1,  say,  is  over  350  degrees  Parenheit 
when  certain  chemical  reactions  are  known  to  take  place.  The  d^jendency 
file  requires  the  channel  (number)  that  must  be  monitored  for  the 
oonditicn,  the  condition  itself,  and  the  channel  that  must  be  read  when 
the  condition  is  satisfied. 

A  channel  control  file  is  needed  when  the  system  is  to  be  also  used 
as  an  esqjeriment  controller.  In  this  configuration,  one  or  more  of  the 
scheduled  chcinnels  (defined  in  the  channel  schedule  file)  may  be 
monitored  and  their  values  oorpared  against  a  given  range.  One  of  two 
actions  is  taken  when  this  value  does  get  out  of  range:  a  message  is 
printed  on  the  operator's  terminal  or  a  ^)ecified  output  channel  is 
adjusted  accordingly.  The  control  cheinnel  file  therefore  includes  the 
low  and  high  values  of  the  required  range,  the  appropriate  action  v^n 
the  control  channel  value  gets  out  of  this  range,  the  output  channels 
when  tlie  control  channel  value  is  below  and  over  the  range, 
re^ectively,  and  the  message  text,  if  operator  interaction  is  required. 

For  each  of  the  above  channel  definitions,  the  user  is  given  the 
opportunity  to  dieck  his  entry  lines  and  modify  them  as  he  wishes. 
Hiese  change  cptions  include  the  ability  to  change  any  single  line, 
change  all  lines,  add  a  new  line,  or  delete  an  existing  line. 
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Set/Chanqe  Pareiineters.  When  the  portable  autanated  data  acquisition 
astern  is  also  to  be  used  as  an  experiment  controller,  a  function  to 
set,  reset,  or  change  experiment  peirameters  is  required.  This  mechanism 
Ceui  either  be  manual  or  automatic.  The  control  channels  are  monitored 
and  their  values  continually  oonpared  against  given  ranges.  When  a 
channel  reading  does  get  out  of  its  specified  range,  the  proper 
adjustm^ts  nust  be  made. 

Aoquire  Data.  Within  its  ^eed  capabilities,  the  system  must  be  able  to 
sanple  the  analog  signals  present  on  the  defined  data  channels  and 
convert  these  into  digitcil  data.  These  read  times  are  available  frcm 
the  channel  schedule  file  and  readings  nust  be  made  as  closely  as 
possible  to  the  indicated  read  times.  Once  a  scheduled  channel  is  read, 
its  next  read  time  is  updated  using  the  time  interval  between  channel 
reads.  If  there  is  enough  time  before  the  next  scheduled  read  time,  the 
channel  dependencry  file  is  also  checked.  Any  dependent  channel  that  has 
its  dependency  conditions  satisfied  must  be  read,  and  its  read  time 
subsequently  updated.  If  a  control  channel  file  is  present,  it,  too, 
must  be  checked. 

Store  Data.  If,  after  reading  a  scheduled  or  a  dependent  channel,  its 
internal  storage  capacity  is  reached,  the  system  must  be  able  to  dunp 
whatever  data  has  been  collected  to  seme  permanent  storage  medium.  Data 
collectico  can  then  prcceed  as  before. 

Depending  cn  the  time  interval  between  scheduled  chcinnel  reads, 
some  data  may  be  lost  while  storing  one  batch  of  data  into  the 
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tendrwl^s  recxjrding  equipment-  The  operator  is  given  the  option  to 
traneanit  the  acquired  data  before  the  system''s  intemid  storage  (memory) 
is  full,  so  that  shorter,  but  obviously  more,  time  intervals  will  be 
spent  tzansferring  his  blocks  of  data. 

Sonmarv 

chapter  discussed  the  context  analysis  step  in  the  software 
recpiirements  definition  phase.  It  also  presented  the  software 
fonctional  specifications  in  a  general,  informal  manner.  Softwcire 
functions  included  defining  the  experiment,  controlling  parameters, 
acquiring  data,  and  storing  data.  These  ^lecifications  will  now  be 
fotmally  presented  in  the  next  chapter. 
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IV.  EXinctional  Specifications 


Intrcx3uction 


The  formal  functional  spec ificaticans  for  the  ^stem  aure  developed 
using  the  initial  version  of  ICAM  Definition  Method  (IDEPO) .  Its 
fundamental  concept  is  a  oombination  of  structured  analysis  <X)nc^ts. 
T\(0  of  these  concepts  are  to  understand  a  system  by  creating  a  model 
that  graphically  shows  things  (objects  or  information)  and  activities 
(performed  by  men  or  nachines)  and  to  structure  a  model  as  a  heirarchy 
with  major  functions  at  the  tcp  and  successive  levels  revealing 
well-bounded  details.  In  IDEPO,  this  model  is  in  the  form  of  diagrams 
which  are  oonposed  sinply  of  boxes  and  arrcws,  boxes  r^resenting 
activities  and  arrows  representing  things  (Ref  5) . 

Creating  the  diagrams  for  the  proposed  data  acquisition  system  is 
facilitated  by  the  discussion  of  the  major  functional  requirements  in 
the  previous  chapter.  This  ch^ter  presents  the  subdivision  of  these 
functions  into  smaller  subfunctions,  in  the  form  of  diagrams,  which  make 
qp  the  model  for  the  system. 


Activity  Model 

The  initial  step  in  the  discussion  of  the  activity  model  is  to 
present  the  model  in  the  form  of  a  node  index.  Here  the  relatonships 
^mong  the  different  nodes  oorprising  the  model  is  exposed,  eu>d 
understanding  the  model  is  enhcinced.  This  node  index,  showing  the  order 
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of  the  node  diagrams,  is  shown  in  Table  II.  line  detailed  functional 
requironents  are  given  in  the  following  diagrams,  starting  with  node 
A-0,  Mcunage  Data  Acquisition. 

Table  II.  Node  Index 

AO  Manage  Data  Acquisition 
Al  Define  Experiment 

All  Determine  File  IVpe 
A12  Create  Schedule  File 
A13  Create  Dependency  File 
A14  Create  Control  File 
A2  Set/Change  Parameters 
A21  Check  Control  Value 
A22  Determine  Correct  Setting 
A23  Automatically  Adjust  Channel 
A24  Manually  Set  Parameter 
A3  Acquire  Data 

A31  Read  Scheduled  Channel 
A32  Update  Schedule  File 
A3 3  Read  Dependent  Channel 
A34  Update  D^>endency  File 
A4  Store  Data 

A41  Generate  Start-Receive  Signal 

A42  Receive  Data 

A43  Generate  Stcp-Receive  Signal 


The  portcible  data  acquisiticxt  system  is  cJble  to  oonduct  the 
ejqperimait  and  c»llect  data  through  cxxranands  given  by  the  operator. 
Inputs  include  operator  informaticxi  provided  via  his  terminal  and  the 
euiedog  voltages  supplied  from  the  ©speriment  output  lines.  Messages  may 
be  given  to  the  operator  for  proper  (corrective)  actions,  while  the 
collected  data  are  written  onto  a  minicassette  tape  available  on  the 
aperator‘’s  portable  terminal. 
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Tlie  acquisition  of  data  and  the  control  of  the  ejqjeriinent  consists 
of  four  major  functions:  defining  the  e}^riment  in  terms  of  the 
sanpling  strategy  for  the  selected  data  channels  (1) ;  setting  the 
necessary  equipment  parameters  to  the  desired  values,  whether  manually 
or  automatically  (2) ;  actually  reading  the  data  within  the  ^>ecified 
time  frame  (3) ;  and  storing  the  data  for  transfer  to  the  mainframe 
oonputers  for  archiving  and/or  further  reduction  (4) .  Define  Ejcperiment 
provides  channel  information  to  both  the  Set/Change  Parameter  and  the 
Acquire  Data  functions:  to  make  sure  that  the  channel  parameters  are 
within  the  correct  bounds  and  to  provide  the  proper  time  frame  for 
reading  the  channels,  respectively.  Acquire  Data  is  also  dependent  upon 
the  generation  of  the  proper  signal  in  Set/Change  Parameter.  When  data 
gathering  is  conplete,  when  system  memory  is  full,  or  v^hen  directed  by 
the  operator,  the  data  collected  is  stored  by  dunping  it  to  the  portable 
terminal's  minicassette. 
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Define  Esqjeriment  provides  the  necesseiry  sanpling  strategy  and 
control  information  in  terms  of  three  channel  files.  Three  subordinate 
functions  create  these  files:  Create  Schedule  File  (2) ,  Create 
Dependency  File  (3) ,  and  Create  Control  File  (4) .  While  the  contents  of 
these  files  are  different/  the  manner  in  which  they  are  created  is  not. 
Once  a  file  type  is  determined  (1),  the  file  is  built  up  by  having  the 
operator  type  in  a  line  of  information  according  to  the  format  shown  in 
his  terminal. 
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Figure  8.  Node  A2.  Set/Change  Parameter 


One  of  the  files  generated  by  the  Define  Experiment  function  is  a 
channel  control  file.  This  file  is  checked  every  time  a  control  channel 
is  read  (1) .  This  value  may  or  may  not  be  within  the  correct  range  for 
proper  controlling  of  the  experiment  (2) .  If  not,  a  parameter 
associated  with  this  channel  must  be  properly  adjusted,  either 
automatically  (3)  or  manually  (4) . 
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Figure  9.  Node  A3.  Acquire  Data 
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Data  is  acquired  by  reading  the  scheduled  channels  during  the 
afjprcpriate  times  (1).  Other  channels  nay  also  have  to  be  read  during 
this  time  frame,  if  certain  ODnditions  are  met.  Ttiese  c»re  called  the 
dq>endent  channels  (3) .  The  schedule  file  and  the  dependency  file  are 
updated  (2  and  4)  during  this  activity  to  reflect  the  next  scheduled 
time  when  these  channels  are  to  be  read  again. 

The  analog  signals  eire  eiperiment  output  signcils  that  nust  be 
mcnitored.  When  these  signals  are  weak  such  that  they  are  not  cepable 
of  driving  the  analog-to-digital  converter,  they  are  first  amplified  to 
the  proper  range.  This  is  a  hardwaire  function  aind  is  not  shown  in  the 
diagram. 
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Once  data  acquisition  is  oonpleted,  or  when  the  system  memory  is 
full/  or  when  directed  by  the  cperator,  the  data  is  dunped  fran  the 
system  memory  to  the  minicassette  available  on  the  operator's  terminad. 
Iliis  requires  a  Stcirt-Receive  signal  (1)  to  activate  the  tape  drive 
mechanism  for  the  proper  receipt  of  data  (2) .  A  Stqp-Receive  signal  (3) 
is  generated  vAien  aLLl  of  the  data  is  received.  Ccire  mast  be  taken  in 
order  not  to  overflow  the  capacity  of  the  minicassette.  As  much  packing 
of  integer  data  as  possible  must  be  incorporated  into  the  program  for 
maximum  use  of  the  minicassette#  e^ecially  when  a  lot  of  data  has  to  be 
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Summary 


This  chapter  presented  the  formal  functional  specifications  for  the 
porteUsle  data  acquisition  system  in  terms  of  the  diagramming  oonventions 
of  IDEFO.  The  relationships  among  the  different  nodes  and  the  flow  of 
data  between  them  eire  new  evident.  These  diagrams  provide  a  very  good 
foundation  toweirds  designing  the  software.  A  set  of  specifications  has 
been  developed  against  which  the  softwcire  can  be  oonpared. 
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V. 


System  Design 


Introduction 


A  principle  of  structured  analysis  states  that  an  exposition  of  a 
certain  problem  can  be  performed  recursively  through  a  systonatic 
breaking  down  of  the  subject  natter  into  six  or  less  oonponent  parts 
(Ref  5:Chapter  2,2-2).  It  is  a  gradual,  top-dcwn  deconposition 
cqpproach,  leaving  nothing  out  at  any  stage.  Ihe  end  result  is  an 
cinalysis  expressed  in  well-structured  diagrams  that  enhance  an 
understanding  of  the  requirements  for  the  solution  of  the  original, 
cottplex  problem.  These  requirements  can  then  be  translated,  in  a 
rigorous,  organized,  efficient  and,  above  all,  understandable  fashion, 
into  actual  system  design. 

The  diagrams  of  the  previous  chapter  lend  themselves  well  to  the 
design  of  the  softwcire  for  the  portable  data  acquisition  system.  The 
four  major  functions  are  grouped  into  "run  preparation"  and  "run 
experiment"  categories  according  to  their  time  of  occurrence.  Define 
Experiment  falls  into  the  first  category,  as  well  as  the  initial  setting 
of  ejqperiment  p2u:ameters.  Data  collection  and  any  follov^-on 
setting/changing  of  parameters  occur  during  the  actual  running  of  the 
experiment.  Data  storage  (durtping  into  tape)  may  be  done  while  the 
experiment  is  running;  usually,  however,  it  occurs  after  the  experiment 
has  terminated. 

Using  the  same  heirarchical  approach  as  IDEPO  proposes,  the  basic 
functions  are  designed  and  the  results  presented  in  this  chapter. 
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Structure  Qiarts 


The  overall  structure  of  the  softwcire  system  is  shown  in  Figure  11. 
Each  box  r^resents  a  (program)  module;  that  is,  a  oollectiOTi  of 
executable  program  statements  v^ich  is  a  closed  subroutine,  can  be 
called  from  any  other  module  in  the  program,  and  has  the  potential  of 
being  independently  oonpiled  (Ref  9:11) .  Note  the  striking  similarity 
between  the  program  structure  and  the  functional  ^)ecification  diagrams 
of  the  previous  chc5)ter.  This  is  no  coincidence.  The  ultimate 
objective  of  structured  analysis  and  design  is  to  eliminate  the 
ambiguities  and  the  oftentimes  random  relationships  between  the  modules 
that  make  ip  the  whole  program.  In  the  structure  of  Figure  11,  each 
module  has  its  own  particulair  function  to  perform,  which  is  nicely 
broken  down  into  sirtpler  oonponent  functions  by  lower~level  modules 
(Figures  12~26) .  The  lowest- level  modules  perform  elementary  functions. 

The  data  flow  among  the  program  modules  is  exhibited  in  tabular 
form  under  each  deoonposition  figure  in  the  manner  suggested  by  Myers 
(Ref  9:110-121) .  The  IN  and  CUT  columns  refer  to  input  and  output  data, 
re^ectively;  the  numbers  refer  to  the  interface  labels  shewn.  An 
input  datum  is  something  whose  value  is  significant  upon  entry  to  the 
called  module  whereas  an  output  datum  is  something  whose  value  is 
assigned  or  changed  within  the  called  module.  It  is  therefore  possible 
for  a  data  item  to  be  both  an  input  and  an  output  (Ref  9:15). 
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Figure  11.  Program  Structure  for  the  Portable  Data  Acquisition  System 
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Figure  12.  Decomposition  of  “Manage  Data  Acquistion' 


Figure  13.  Decomposition  of  "Define  Expenmcni' 
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Figure  14.  Decomposition  of  "Run  Experiment 
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Figure  15.  Deccmposition  of  'Create  Schedule  File' 
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Figure  16.  Decomposition  of  ‘Create  Dependency  File' 
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Figure  18.  Decomposition  of  "Get  Parameters 
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Figure  19.  Decomposition  of  "Read  Scheduled  Channels" 
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Figure  10.  Decomposition  of  "Read  Dependent  Channels 


Figure  2  1.  Decomposition  of  “Control  Experiment”. 
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Figure  22.  Decomposition  of  "Store  Collected  Data' 
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Figure  23.  Decomposition  of  "Check  RT  1  1  Use 
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Figure  25.  Decomposition  of  “Read  All  Channels 


Figure  26.  Decomposition  of  "Update  Read  Times 


Suitnarv 


The  structure  of  the  software  ^stan  was  revealed  in  this  chapter. 
The  deconposition  of  the  higher-level  mcdules  was  presented  and  each 
module-module  interface  defined  according  to  the  data  that  flow  between 
them.  Against  this  backdrop,  coding  the  software  is  made  a  lot  easier, 
which  is,  not  coincidentally,  the  next  phase  in  the  development  effort. 
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VI.  Remaining  Develcpment  Phases 


Introduction 


With  the  structure  of  the  softwcure  designed  and  optimized,  it  would 
seem  that  the  next  step  is  to  design  the  logic  (algorithm)  of  the 
modules  and  code  it  in  the  c^rcpriate  programming  language.  Myers 
advocates  yet  another  intervening  step,  however,  a  step  he  calls  "module 
interface  design".  The  purpose  of  module  interface  design  is  to 
produce,  for  each  module,  a  module  interface  ^secification  describing 
precisely  the  function  and  interface  of  the  module.  The  information 
needed  in  the  ^ecification  includes  the  module  (or  entry-point)  name, 
the  function  of  the  module,  the  number  and  order  of  the  arguments,  the 
iiput  arguments  (their  meaning,  format,  size,  attributes,  units,  and 
valid  domain) ,  the  output  arguments  (their  meaning,  format,  size, 
attributes,  units,  and  valid  range),  and  the  external  effects  (actions 
external  to  the  system,  e.g.  irput/output  operations)  (Ref  9:148-149). 

The  module  interface  specifications  provide  an  excellent 
documentation  mechanism,  but  are  not  included  here;  rather,  they  will 
be  incorporated  in  the  program  code  where  they  are  most  useful.  A 
listing  of  the  program  will  be  submitted  to  the  Materials  Laboratory  for 
inclusion  in  their  application  programs  library.  Future  maintenance 
programmers  will  find  this  documentation  very  valuable  and  they  will 
have  easy  access  to  it. 

The  remaining  phases  of  the  software  development  for  the  portable 
data  acquisition  system  are  discussed  in  this  chapter. 
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CcxJe 


Ocrfing  the  program,  given  a  good  structure,  becomes  almost 
mechanical  (Ref  7:119).  This  does  not  mean,  however,  that  the  structure 
be  followed  rigidly,  with  no  deviations.  In  fact,  the  "module  interface 
design"  step  revealed,  and  the  code  implemented,  the  need  to  slightly 
modify  the  data  flow  as  shown  in  the  design  chapter.  In  particular,  the 
channel  schedule,  dependency,  and  control  files  are  no  longer  passed 
between  modules  as  arguments  but  cure  rather  shared  by  modules  through 
the  use  of  named  C!OMON  blocks.  This  introduces  "pathological  data 
connections"  (Ref  19:242)  between  modules  which  create,  from  a 
structured  design  point  of  view,  an  undesirable  coijpling  condition. 
However,  these  channel  files  each  contain  a  group  of 
functionally-related  data  items  and  together  total  mote  than  a  trivial 
number  of  arguments  to  pass  from  module  to  module.  And  although  still 
open  for  debate,  the  number  of  modules  these  files  have  to  pass  through 
makes  the  claim  credible  that  this  can  cause  a  discernible  effect  in  the 
speed  of  the  program  execution. 

The  relative  ease  of  coding  the  program  does  not  inhibit  one  frcm 
using  pre-existing  modules,  either.  This  is  in  fact  encouraged  (Ref 
9:4).  In  the  Materials  Laboratory,  a  number  of  small  programs  have  been 
written  for  specific  data  acquisition  systems.  The  Assembly  program  to 
drive  the  ADAC  A/t)  and  D/A  converter  and  the  clock  interrupt  routine  are 
incorporated  in  the  portable  data  acquisition  software.  These  modules 
expect  (J0^^10N  blocks  for  the  values  read  ficm  the  converter  and  the 
running  clock  time  information. 
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Data  Collection  Algorithm.  The  top-down  approach  to  the  deoonposition 
of  the  program  nodules  makes  it  easy  to  understand  what  each  module 
performs.  The  lowest  of  these  modules  perform  elementary  functions  and 
are  not  difficult  to  code.  The  inplementation  of  sane  higher-level 
modules,  however,  is  more  oorplex  and  needs  more  elucidation.  For  this 
purpose,  the  algorithm  for  the  data  oollection  is  presented  below. 

1.  Scheduled  channels  are  read  ^regularly^  -  as  closely  as  possible  to 
the  scheduled  read  times. 

a.  All  channels  are  cxmtinuously  scanned  through  the 
analog-to-digital  cx>nverter.  The  values  read,  along  with  the  time  of 
this  read,  are  placed  in  a  buffer.  A  determination  is  then  made  whether 
to  save  this  tenporary  data  or  not. 

b.  If  the  actual  read  time  is  within  Ml  milliseconds  (see  point  8 
below)  before  the  scheduled  read  time,  the  data  in  the  buffer  is  stored. 
If  it  (actual  read  time)  is  already  past  the  scheduled  read  time,  the 
data  is  cLLso  stored,  in  addition  to  checking  the  conditions  in  2  below. 
Otherwise,  the  data  is  discarded  (overwritten) . 

2.  If  the  actual  read  time  overruns  the  scheduled  read  time,  the  actual 
read  time  is  checked  to  see  if  it  is  within  one-half  the  time  interval 
(between  scheduled  reads)  from  the  scheduled  read  time.  If  it  is,  the 
scheduled  read  time  is  incremented  by  the  corresponding  channel  time 
interval  to  get  to  the  next  read  time.  If  it  is  not,  the  scheduled  read 
time  is  incremented  by  as  many  time  intervals  as  necessary  to  get  it 
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within  one-half  the  time  interval  from  the  actual  read  time;  the 
ch2mnel  values  read  then  correspond  to  this  updated  scheduled  read  time, 
and  nonnal  incrementing  is  resumed.  The  ski^Jed  scheduled  read  times 
are  siiiply  missed. 

3.  If  there  is  a  channel  scheduled  to  be  read  within  M2  milliseconds 
(see  point  8  below)  of  the  actual  channel  read  time,  no  dependency  check 
is  nade  unless  as  specified  in  4  below. 

4.  If  the  time  interval  between  scheduled  channel  reads  is  such  that  a 
defined  channel  dependency  file  is  not  being  checked  (there  is  always 
one  channel  or  another  to  read  within  M2  milliseconds  of  yet  another) ,  a 
mechanism  is  included  to  force  a  dependency  check  after  every  fifth 
actual  read  and  storage  of  channel  data  (this  condition  was  approved  by 
the  Laboratory  ^xsnsor) . 

5.  A  dependency  check  is  nade  whenever  time  is  available  or  forced  by 
conditions  in  4  as  long  as  there  is  at  least  one  active  dependent 
channel.  The  set  of  originally  defined  dependent  channels  is  scanned 
cind,  if  active,  the  value  of  the  corresponding  independent  channel  is 
tested  with  the  given  conditions  and  values.  If  the  conditions  are  met, 
the  dependent  channel  is  read,  the  value  is  stored,  and  the  proper 
disposition  rule  is  enforced. 

6.  Once  satisfied,  a  dependency  status  nay  be  turned  off  or  let  to 
remain  cn.  When  turned  off,  the  dependent  channel  may  be  read 
regularly,  if  desired,  and  added  to  the  channel  schedule  file. 
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7.  A  dependency  check  for  each  independent  channel  can  be  made  only 
between  siuccessive  actual  reads  (and  storages)  for  the  independent 
channel,  and  then  only  once  during  this  span  (i.e.,  multiple  dependency 
checks  between  successive  channel  reads  are  not  allowed) . 

8.  Ml  was  initially  given  the  value  of  10  milliseconds;  M2  was  given 
the  value  of  20  milliseconds.  Using  the  algorithm  discussed  eibove,  the 
program  was  tested  with  only  a  channel  schedule  file  defined.  The  time 
interval  used  was  2  milliseconds  to  force  the  fastest  channel  reads 
possible.  (This  is  not  optimum  because  of  point  2  above.)  The 
foHcwing  results  were  recorded: 

Number  of  Average  Time 

Scheduled  Channels  Between  Reads 

1  4.25  msec 

2  8.00  msec 

3  12.00  msec 

4  16.10  msec 

15  50.20  msec 

A  channel  dependency  file  (with  only  one  channel  defined)  was  added  to 
the  above  best.  If  no  dependency  check  has  to  be  made  (point  3) ,  the 
fastest  a  scheduled  channel  can  be  read  is  reduced  to  once  every  12 
milliseconds.  If  a  dependency  check  is  made  but  the  condition  is  not 
satisfied  (no  dependent  channel  is  read) ,  the  scheduled  channel  read  is 
further  slowed  down  bo  once  every  14  milliseconds.  If  the  condition  is 
met,  the  rate  deteriorates  to  once  every  18  milliseconds. 

Given  the  statistics  above,  the  values  of  10  milliseconds  for  Ml 
and  20  milliseconds  for  M2  were  retained. 

Control  Algorithm.  As  stated  earlier,  control  of  the  experiment  is  a 
rather  primitive  operation.  It  is  brplemented  by  placing  a  cotrputed 


digital  value  into  the  proper  input  port  of  the  digital-to-analog 
converter  and  routing  its  analog  output  to  the  cpprcpriate  experiment 
control  equipment.  Before  the  actual  start  of  the  experiment,  this 
digital  value  is  initialized  by  the  operator.  This  analog  voltage 
causes  some  physical  phenomenon  to  happen,  the  effect  of  which  is,  in 
turn,  measurable  by  an  analog-to-digital  converter.  The  output  of  the 
analog-to-digital  converter  is  monitored  via  a  control  channel. 

For  prcper  oontrol  of  the  experiment,  the  control  channel  value 
must  be  within  a  given  range  (also  operator-defined) .  If  it  is  not,  the 
digital  input  value  to  the  d/a  converter  is  adjusted  up  or  down 
depending  on  which  out-of-range  condition  exists  by  a  certain  correction 
value  also  initialized  by  the  operator.  This  digital  input  value  is 
continually  adjusted  until  such  time  that  the  oontrol  channel  value  is 
within  the  ^ecified  range.  If,  however,  the  range  is  narrow  and  the 
control  channel  value  skips  from  one  side  (of  the  range)  to  the  other  in 
one  adjustment,  the  correction  value  is  halved  and  (finer)  adjustments 
in  the  opposite  direction  proceed  as  before. 

Debug 


The  ease  of  debugging  any  oomputer  program  depends  heavily  upon  how 
the  code  is  written.  The  use  of  clever,  exotic  algor ithmis  tend  to 
conplicate  otherwise  sinple  progr2ims.  And  when  an  error  is  indicated, 
finding  and  correcting  it  can  be  very  frustrating.  In  the  software  for 
the  portable  data  acquisition  system,  this  type  of  algorithms  is 
avoided.  There  is  no  reason  for  using  such  algorithms:  the  modules 
perform  sitrple,  recognizable  functions. 
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Errors  do,  and  did,  occur  however.  But  their  identification  and 


correction  was  helped  tremendously  by  means  of  the  debugging  tools  on 
the  PDF  11/03  development  system.  The  use  of  the  debugging  statement 
indicator  (letter  D  in  Fortran  statement  column  1) ,  and  the  use  of  the 
On-Line  Debugging  Technique  (ODT)  were  the  tools  most  often  utilized  in 
this  project.  In  addition,  numerous  input  data  checking  statonents  were 
added  to  the  code  because  "debugging  input  data  is  as  iirportant  as 
debugging  a  program"  (Ref  6:87).  Strategically  located  print  statements 
of  specific  error  messages  were  also  used  abundantly  throughout  the 
program.. 

Test  and  Integration 


The  top-down  deccrtposition  technique  has  one  other  very  practical 
feature:  it  allows  the  programmer  the  ability  to  use  "stub  modules". 
These  are  modules  that  are  written  to  simulate  the  functions  of 
subordinate  modules.  In  using  this  technique,  the  tcp  module  in  the 
program  is  coded  and  tested  using  stub  modules  for  all  the  modules  it 
calls.  Once  the  tcp  module  has  been  tested,  one  of  its 
immediate-subordinate  modules  is  coded,  the  two  modules  are'  integrated 
together  along  with  the  necessary  stubs,  the  ocnibination  is  tested,  and 
so  forth  (Ref  9:147).  This  technique  worked  very  well  in  this  project 
because  the  particular  format  selected  to  inplement  the  system  (at  least 
the  higher-level  portion)  is  the  command  format.  In  this  manner,  each 
of  the  next-to-tcp  level  modules  is  invoked  according  to  which  oommand 
the  user  gives  interactively  with  the  program.  Going  further  down,  each 
of  the  channel  files  is  created  by  the  reductive  module  also  according 
to  the  type  interactively  specified  by  the  user. 


Initial  test  and  integration  was  performed  at  the  PDP  11/03 
develcpmofit  site  on  those  routines  not  requiring  the  use  of  the  clock. 
After  this  portion  of  the  code  had  been  tested  and  integrated,  the 
portable  data  acquisition  systen  itself  was  used.  A  dual  floppy  disk 
drive,  with  the  RT-ll  system  floppy  disk  on  one  drive  and  the  portable 
system  software  cn  the  other,  was  utilized  in  this  test  and  integration 
phase.  An  HP  3312A  Function  Generator  was  used  to  generate  predictable, 
known  signals  for  irput  to  the  analog- to-digital  converter. 

Operations  and  Maintenance 


A  program  may  be  subjected  to  extensive  test  and  integration 
procedures  but  its  real  test  is  hew  it  holds  ip  in  actual  practice.  The 
portable  data  acquisition  system  has  been  used  in  two  different 
experiments  in  the  Materials  Laboratory;  high  performance  liquid 
chresnatography  and  thermal  analysis  of  polymers.  In  both  of  these 
experiments,  only  a  few-hundred  data  points  were  collected.  Ihese  data 
points  were  plotted  and  oonpared  with  strip-chart  recordings  made 
concurrently  with  the  data  acquisition  process.  The  results  show  a 
general  resemblance  between  corresponding  plots:  the  big  difference  is 
the  presence  of  intermittent  noise  spikes  on  the  plots  generated  by  the 
portable  system.  The  noise  problem  has  been  reduced  significantly  since 
then;  but  it  still  persists. 

It  should  be  mentioned  that  the  thermal  analysis  exqxeriment 
required  only  a  straightforward  data  collection  capability.  The  liquid 
chromatography  set-up  had  two  output  channels,  and  they  were  used  as  an 
independent-dependent  channel  pair.  There  was  no  real  need  to  collect 
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data  on  very  short  inter Veils  either,  so  the  data  collection  algorithm 
has  not  really  been  "pushed"  except  during  the  testing  phase.  The 
cxantrol  routines  have  not  yet  been  exercised  on  an  actual  experiment  as 
well.  Therefore,  there  has  been  no  occasion  so  far  to  perform  vrfiat  can 
truly  be  considered  maintenance  programming.  When  the  situation  arises, 
the  programmer  should  find  anple  documentation  to  make  his  job  easier. 

Summary 

Hie  remaining  phases  of  the  software  development  were  discussed  in 
this  chapter.  They  appear  sinple  and  straightforward.  But  this  is  only 
deceptively  so.  The  efforts  put  forth  in  the  previous  phases  make  the 
rest  of  the  development  job  relatively  easy. 
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VII.  SummaQf  and  RecomiendatiOTs 


The  software  development  effort  discussed  in  this  thesis  gives  one 
the  inpression  of  a  smooth,  ordered  transition  fran  one  phase  to  the 
next.  Actually,  there  was  a  significant  amount  of  overlap  between  them, 
even  a  ootple  of  conplete  iterations  frcm  the  design  of  the  structure  to 
the  writing  of  the  code.  This  is  not  normally  encouraged;  the  relative 
size  of  this  effort  made  such  iteration  possible  in  this  case. 

The  software  was  designed  and  coded  using  structured  design 
techniques  which  enphasize  modularity  of  oenponents.  Higher  level 
modules  are  logically  broken  down  into  smaller,  siitpler  modules.  While 
this  technique  really  does  make  understanding  the  software  system 
easier,  it  does  tend  to  increase  the  size  of  the  program.  For  this 
project,  such  increase  was  minimal  but  did  have  an  irrpact  on  the  overall 
scheme  of  the  system.  For  this  size  of  an  effort  also,  there  is  a 
nornal  tendency  to  view  the  emphasis  on  structured  programming 
techniques  as  a  nuisance;  that  these  techniques  make  much  more  impact 
on  larger  systems.  However,  as  has  already  been  mentioned,  its 
documentation  value  alone  makes  the  use  of  these  techniques  very 
worthwhile. 

Summary 

Hie  stated  purpose  of  this  study  was  to  develop  the  software  for 
the  portable,  generalized  experiment  control  and  data  acquisition 
system.  By  meticulously  following  the  software  development  phases 
recommended  by  the  Air  Force,  this  software  product  is  now  operational 
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and  has  indeed  been  used  on  two  Materials  Laboratory  experiments.  The 
results  from  these  experiments  show  the  collected  data  with  a 
significant  amount  of  noise.  However,  this  is  recognized  as  a  hardware, 
most  probably  pcwer  supply,  problem  and  does  not  indicate  software 
insufficiency.  Any  program  errors  uncovered  during  the  operational 
phase  of  the  software  life  cycle  {which  this  project  is  in  new)  will  be 
corrected  by  the  maintenance  programmer. 

In  addition  to  the  power  sujply  problem  briefly  mentioned  above, 
the  project  was  also  delayed  considerably  during  the  later  stages  of  the 
development  because  of  the  insufficiency  of  the  portable  terminal's 
minicassette  tapes.  It  was  initially  expected  that  any  software  written 
for  the  data  acquisition  system  would  fit  on  one  side  of  a  minicassette 
tape.  This  may  have  been  the  case  but  for  the  generality  of  the 
program.  The  use  of  structured  design  techniques  may  also  have  added  to 
the  size  of  the  program.  However,  it  was  felt  that  any  drastic  cut  of 
the  program,  in  terms  of  its  generality  and  of  its  structure,  would 
seriously  inpact  the  ease  of  its  use  and,  ultimately,  its  maintenance. 
In  addition,  a  force  fit  into  one  minicassette  side  leaves  no  roan  for 
possible  enhancements  or  modifications.  If  this  room  is  ever  needed 
later,  for  any  reason  at  all,  then  one  is  back  to  contending  with  the 
same  problem. 

In  an  effort  bo  solve  this  problem,  a  program  was  written  to 
"cleanly"  break  the  resulting  stand-alone  file  into  two  pieces,  loading 
each  piece  into  one  side  of  a  minicassette  tape.  Loading  the  two  pieces 
of  file  from  the  minicassette  tape  to  the  portable  data  acq’aisition 
system  resulted  in  numerous  loading  errors.  Using  degaussed  tapes  as 


suggested  by  the  portable  terminal  manufacturer  reduced  the  number  of 
errors;  nevertheless,  the  program  load  was  still  unsuccessful. 
1t»erefore,  the  initial  system  requirement  bo  be  able  to  load  the 
stand-cilone  program  file  from  the  portable  terminal's  minicassette  tapes 
to  the  data  acquisition  system  was  not  satisfied.  Currently,  the 
portable  data  acquisition  system  can  be  used  only  through  the  use  of  a 
dual  floppy  disk  dri/e,  which  is  the  configuration  used  during  the 
testing  and  initial  operational  phases  of  the  development. 

Reccmmendations 

Meaningful  recommendations  for  follow-on  efforts  to  the  topics 
considered  in  this  thesis  revolve  mainly  around  possible  enhancements  to 
the  system.  First  of  all,  since  the  automatic  control  algorithm  is 
admittedly  primitive,  a  more  sophisticated  mechanism  may  be 
incorporated.  It  must  be  kept  in  mind,  however,  that  the  system  memory 
size  is  very  limited  and  care  nust  be  taken  not  to  incorporate  too 
extensive  an  algorithm.  Secondly,  there  is  not  now  any  convenient  means 
to  abort  the  program  except  tfirough  the  use  of  the  conputer  RESETT 
button.  Pressing  this  button  immediately  stops  the  program  and  resets 
the  conputer.  If  another  e>qperiment  run  is  contemplated,  the  program 
must  be  re-loaded.  A  different  abort  technique  is  definitely  in  order. 
Thirdly,  the  thermal  analysis  experiment  exposed  a  deficiency  in  the 
5inalog-to-digital  conversion  method.  Previous  data  oollections  made 
with  an  HP  ooupler-oontroller/paper  tape  arrangement  show  data  beyond 
the  range  selected  on  the  thermal  analysis  equipment.  This  means  that 
einy  spikes  on  the  analog  input  signals  are  properly  and  continuously 
recorded.  Oi  the  portable  data  acquisition  system,  any  readings  outside 
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Appendix  A 


Sanple  Program  Code 

The  sanple  program  oodes  are  given  below  to  provide  a  feel  for  what 
the  code  looks  like.  In  particular,  the  portion  of  the  code  for  the  main 
program,  GEXDAS,  is  provided  to  give  the  reader  the  details  of  the  channel 
files  mentioned  in  Chapters  III  and  TV.  The  format  for  the  introductory 
oonments  for  each  module  is  that  of  Myers,  specifically  the  module 
interface  ^ecifications.  Other  comments,  along  the  same  lines,  are  the 
author's. 


PRDGRAM  GECDAS 
C 

cxrcocroccnxmrcrDxcxxaxoDXCcxxrara^Dooocccaxcccccoccacccoccxx^^ 

c 

C  FUNCTION:  THIS  IS  THE  MAIN  PPDGRAM  FOR  THE  GENERALIZED  EXPERI>D7r 

C  CONTROL  AND  DATA  ACQUISITIOI  SYSTSi  (GECDAS)  . 

C 

C  INTERACTIVE  COf-t-lANDS  ARE: 

C  EEFINE  -  lEFINE  DATA  COLLECTION  CHANNELS 
C  HELP  -  LIST  ALL  VAID  COr-lAt'JDS 

C  FUN  -  START  EXPERIMENT  CONTROL  AND  DATA  ACQUISITION 

C  STOP  -  STOP  DATA  ACQUISITION  PROGRAM 

C 

c . 

c 

C  SUBPROGRA-e  CALLED: 

C  DEFINE  -  TEFIIJE  DATA  COLLBCTiaj  Q^AN^’ELS 
C  HELP  -  LIST  ALL  VALID  OOflVCOS 

C  PUNEXP  -  START  EXPERIMENT  OONTR  •  /'  .  "ATA  ACQUISITION 

C 

c . 

c 

C  VARIABLES  USED: 


C  VALID  -  LOGICAL  VTiRIABLE  INDICATING  WIETHER  USER-GIVEN  OOf-M/VTO 
C  IS  VALID  OR  NOT  (.TRUE.  OR  .FALSE.) 

C  OOMAND  -  USER-GIVEN  ( INTER/MCTIVELY)  COMMAND 

C 

c . c 

c  C 
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NAMED  CDMtCN  BLOCKS  DEFINITION  C 

C 

SCDATA  (CIIAI3'rEX  SQIEDULE  FILE  DATA)  :  C 

tOIAN  -  NDT’BER  CF  SarEDULED  CHAEiNELS  C 

ICHAN(I)  -  THE  ITH  (SdrmjLED)  CILAE^EL  MI-IBER  DEFINED  C 

Rrif-1E(I,J)  -  SOIEDULED  TE'IE  FOR  IQIAMd)  C 

RriME(i,i)  -  HOURS  caii’affiNT  CF  owMEL  re;>d  time  C 

RriME(l,2)  -  MDJUTES  CQ’-lRGriliir  OF  CHANI-IEL  READ  TIME  C 

RriME(I,3)  -  SECOKT)S  CaiPCNENT  OF  CHAM  EL  READ  TD-E  C 

RriME(I,4)  -  MLLISECC^ES  CXa'EONENT  OF  CH^VCEL  RF-AD  TIME  C 

DriME(I,J)  -  TEE  EfTERVAE  BEE.-EEN  QiAFaEL  READS  FOR  laiAN(I)  C 

DriME(I,l)  -  HOURS  CaiPaENT  CF  T5E  TIME  INl’ERVAL  C 

EmME(I,2)  -  MINUIES  (X^■!PO^E^^’  CF  THE  TE-E  INTERVAL  C 

DriME(I,3)  -  SECONDS  COMPCIENT  OF  THE  TEE  INTER/AL  C 

DrEE(I,4)  -  MILLISECONDS  Oa‘-!POtEOT  OF  THE  TEE  E'ffERVAL  C 

HDTEE(I,J)  -  QE-HALF  OF  OTEEd,!)  ,  HE  TEE  IN’IERVAL  C 

SCALE  (I)  -  SCALE  FACTOR  TOR  CHAi'-JEL  ICHAN(I)  VALUE  C 

DNAMEd)  -  NAAE  GIVEN  TO  OiANME  IQIAiJd)  C 

C 

DPDATA  (aiANNEL  DEPENDENCY  FILE  DATA) :  C 

NDCH  -  NU-EER  CF  DEPd^EaTT  QLANIELS  C 

YCHANd)  -  TIE  ITH  DEPENDlEfT  CHAM'IEL  (NUMBER)  DEFINED  C 

XCHANd)  -  TIE  E'DEPMEENP  GIANNEL  FOR  YCHANd)  ;  I.E.  ,  THE  C 

CHANNEL  UPON  VEOSE  VALUE  YCHANd)  DEPENDS  FOR  READING  C 
aONDl(I)  -  TOGEITER  VJITO  VAUJEl  (1)  ,  IT  MAKES  UP  THE  FIRST  C 

CONDITION  HIA  XOiAaMd)  MIST  >EET  FOR  YCHAMd)  TO  C 

BE  READ;  aai  HAVE  VAUJES  "GT”,  "GE",  "EQ" ,  "LE",  "LT"  C 
OOND2(I)  ,VALUE2(I)  -  MAKE  UP  THE  SECOND  CONDITION,  IF  APPLICABLE,  C 

THAT  xaiANd)  MUST  ^EE^  C 

STA'IUS(I)  -  INDICATES  Iv-HETIER  'THE  DEPENDENCY  CONDITION  FOR  C 

YaiAN(I)  IS  ACl’IVE  OR  NOT  C 

DISPd)  -  IF  HE  DEPENDENCY  STATUS  FOR  YCHAN{I)  IS  ACTIVE  AND  C 
THE  CONDITIONS  ARE  ,'ET,  DISPd)  INDICATES  WHETHER  TO  C 
ISACriVATE  HE  STATUS  OR  NOT  C 

XCHCHK(I)  -  A  DEPENDENCY  QECK  V’HLL  BE  MADE  ONLY  BEIA'EEN  TTO  C 

SUCCESSIVE  SGISVJLED  CHANNEL  READS  AND  HEN  aiLY  C 

ONCE  DURING  THIS  SP.VN;  XCHQKd)  SIGNIFIES,  FOR  C 

THE  CORRESPGNDIt'C  XOtANd)  ,  WIiCTHER  A  DEPENDENCY  C 

CHECK  CAN  BE  LEGALLY  iMAUE  OR  NOT  C 

C 

CNOATA  (CHANNEL  CONTROL  FILE  DATA) ;  C 

NCNTL  -  NUM3ER  CT’  CO:7rRDL  CtIWNELS  C 

OTTLCHd)  -  TIE  riE  CONTROL  CiLMTaE  (NU>BER)  DEFINED  C 

LOVAIU(I)  -  LON  LL'IIT  CF  ,'CCEPT7'iBEE  CNTICHd)  VAUJES  C 

HIVAUJ(I)  -  IHGH  LLMIT  OF  /CCEPTJEIE  aiTTCHd)  VALUES  C 

ACTION  ( I)  -  INDICATES  WJIEHER  MANUAL  OR  /CrQMAIC  RESI'CEE  IS  C 

TAKEN  KIENEVER  HE  VALUE  OF  CNTlCHd)  GETS  OUT  OF  C 
RANGE  C 

LOaiAN(I)  -  WL-ai  CTTLCHd)  VAIUE  GETS  BELCT'J  LOVALUd)  AND  C 

ACTION ( I)  IS  /Cra-ATIC,  LCCHAN(I)  IS  ADJUSTED  C 

ACCORDINGLY  C 

HICHAN(I)  -  MEN  C/TLCHd)  VAiJE  IS  OVER  HF/ALUd)  aCTIONd)  C 
IS  AUTOMATIC,  OUTIUTT  CHANFJIE  HIGLANd)  IS  C 

ADJUSHJD  ACCORDIIJGLY  C 
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OI£»EL(I)  -  THE  RELATIONSHIP  BEIVSEEN  THE  LAST  CONTROL  CHANNEL 
VALUE  AND  ITS  ACCEPTABLE  VALUES;  HAS  ALPHABETIC 
VALUE  "OK"  IF  VALUE  WAS  WITHIN  RANGE;  "HI"  IF 
tARGER  THAN  HIVALU(I)  ;  OR  "LO"  IF  SMALLER  THAN 
LOVALUd) 

DIGITL(J)  -  AEJUSTI-ENrS  ARE  MADE  TO  LOQIANd)  OR  HIGiANd)  (=J) 
BY  LOADING  A  DIGITAL  VALUE  (DIGITL{J))  INTO  THESE 
CHANNELS  WHICH  IS  THEN  CD^:VERTED  TO  THE 
CORRESPONDING  ANALOG  VOLTAGE  FOR  OOTPUT 
DELTA  (I )  -  THE  MAGNITUDE  OF  THE  DIGITAL  ADJUST-lENr,  EITHER 

Ar»ED  TO  OR  SUBTRACTED  FROM  DIGITL(J)  ACCORDING  TO 
OLDRELd) 

MESSAGd,!)  -  FIRST  8  CHARACTERS  OF  MESSAGE  TO  OPERATOR'S 

TEIMLNAL  WHEN  CNTLCH(I)  VALUE  IS  OITT  CF  RANGE 
AND  ACTICWd)  INDICATES  MANUAL  RESPaJSE 
MESSAG(I,2),  MESSAGd, 3)  -  CONTAIN  THE  RE-IAINING  QIARACTERS  OF 

THE  MESSAGE  TO  THE  OPERATOR 

CLKOQM  (CURRENT  CLOCK  INFORMATION) 

HR  -  HOURS  COMPONENT  CF  CURRENT  CLOCK  TIME 
MIN  -  MINUTES  COt^PONENT  OF  CURRENT  CLOCK  TIME 
SEC  -  SECONDS  COMPONENT  CF  CURRENT  CLOCK  TIME 
MSEC  ~  MILLISECONDS  COMPOJENT  CF  CURRENT  CLOCK  TIME 

ADCOM  (ANALOG-TO-DIGITAL  CONVERTER  VALUES) 

JVALUE  -  DIGITAL  CONVERSION  CF  ANALOG  VOLTAGES  PRESENT  IN  THE 
A/D  CHANNELS 


MODULE-MODULE  DATA  CCNNECTION  THROUai  COMMON  BLOCKS 


MODULE 

N  A  ^ 

1  E  D  C  0  M  M  0  ^ 

• 

J  BLOCK  : 

SCDATA 

DPDATA  :  CNDATA 

CLKCXM 

ADCOM 

GEXDAS 

X 

X  :  X 

X 

X 

HELP 

DEFINE 

SCHFIL 

X 

DEPFIL 

X  : 

CONFIL 

;  X 

RSLINE 

X 

DVTIME 

DELETE 

RDLINE 

X  : 

DEFALT 

RCL’^'E 

:  X 

RUNE5CP 

X 

X  ;  X 

PARAMS 

RTll 

INITRT 

RUNID 
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SIGNAL 

STCaPTN 

INITCV 

:  X 

SETCLK 

• 

• 

X 

CLKIOT 

• 

X 

RSaiAN 

X 

CHKDEP 

X  : 

X 

UPCHAN 

X 

X 

X 

CXNEXP 

:  X 

DAC 

STORE 

SNEATA 

GEHTIM 

X 

READCH 

X 

ADC 

X 

ADAC 

SAVE 

X 

X 

UPDATR 

X 

AOTIME 

C 

C 

C 

C 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


**★★★*★★★★*** 


LOGICAL*!  VALID 
KEAL*8  OOMAND 


C 


c 


c 

c 

c 


c 


INrEGER*2  NCHAN,iaiAN(I6)  ,RriME(I6,4)  ,DriME(16,4)  ,HDTE‘E(16,4) 
REAL*8  DNAf-IE(16) 

REAL*4  SCALE (16) 

LOGICAL*!  XCKCHK(!6) 

INrEGER*2  !®CH,Yai\N(I6)  ,XCHAN{16)  ,CCKD!(16)  ,CaiD2(!6)  , 

1  STATUS (16) 

REAL*4  VALUE!(!6) ,VALUE2(16) ,DISP(!6) 

INrEGER*2  ^OrIL,O^L^JCH(!6)  ,L0a!\N(16)  ,HICHAN(!6)  , 

INrEGER*2  OLDR£T.(16) ,DIGrTL(2) ,D£LTA(16) 

REAL*8  ACriOt;  ( 16 )  , MES3AG  (16,3) 

REAL*4  LOVALJ  ( 16 )  ,  HIVALU  ( 16) 

INrEGER*2  HR, MIN, SEC, MSEC 


INrEGER*2  JVALUE(16) 


OCMyiON 

COMMON 

1 

COl'tCN 

1 

COMMON 

COMCIN 


/SCDATA/  NCHAN ,  IQIAN ,  RTIME ,  DT  D^E ,  HDT IME ,  SCALE ,  DNAME 
/DPDATA/  MXH ,  YCUVV,  XCf IVM ,  CCNDl ,  OCNT)2 ,  DISP , 

VALUEl , VALUEX , STATUS , XQiaiK 
/CNDATA/  ^C^LU,Gn^Ja^, ^\CTTO^I, LOaiAN, HiaiAN,MESS.^G, 
LOVALU ,  !ir//'L:i  ,OLDPJ2L,  DIGITL,  DELTA 
/CLKCOM/  HR, MIN, SEC, MSEC 
/ADCOM/  JVALUE 
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non 


C 


CALL  HELP  (VALID) 


NCHAN  =  0 
NDCH  =  0 
NCNTL  =  0 


GEIT  COM^VD 

100  WRITE (5, 1001) 

1001  FORMAT (/2X/COI^4AND?  ',$) 

C 

READ(5,1002,ERR=200)  COMAND 

1002  FORMAT (A8) 

C 

VALID  =  .FALSE. 

IF  (COMAND.  EQ.4HHEILP)  CALL  HELP  (VALID) 

IF  (OOMAND. EQ. 6HDEFINE)  CALL  DEFINE (VALID) 

IF  (COMAND. EQ.3HRUN)  CALL  RUNEXP (VALID) 

IF  (COMAND.  EQ.  STOP)  GOTO  900 

C 

IF  (.NOT. VALID)  WRITE (5 , 1003) 

1003  Et3mT(/2X/INVAID  OOf'MAND;  NO  Cm^lAND  EXECUTED.") 

GOTO  100 

C 

200  WRITE (5, 2001) 

2001  FORMAT (/2X,"*ERROR  -  INVALID  INPUT;  TRY  AGAIN.') 

GOTO  100 
C 

900  CONTINUE 
C 

STOP 

END 
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SUBROUTINE  SNmTA{TCOAY,EXPID,OPERTR,RDriME, CHANEL, VALUE, NDATA) 


C 


c  c 

C  FUNCTION:  WRITE  RUN  INFO  AND  COLLECTED  DATA  OFITO  MINICASSETTE  C 

c  c 

c  CALLING  SEQUENCE:  CALL  SNnATA(TODAY,EXPID,OPERTR,  C 

C  RDTIME,CHANEL, VALUE, NDATA)  C 

C  C 

C  INPUTS:  C 

C  TODAY  -  TCnAY'S  DATE  C 

C  EXPID  -  EXPERI^!E^rT  IDEOTIFICATION  C 

C  OPERTR  -  OPERATOR'S  LAST  NAME  C 

C  RDTIME  -  CH/^rC'EL  READ  TH-IE  C 

C  CHANEL  -  CHANNEL  NUT'SER  C 

C  VALUE  -  SCALED  OW^TEIL  VALUE  C 

C  NEATA  -  NUMBER  CF  DATA  POINTS  C 

C  c 

c  OUTPUTS:  NONE  C 

C  c 

c  EXTERNAL  EFFECTS:  C 

C  COLLECTED  CAT/..  ARE  WRITTEN  ONTO  THE  TERMINAL  MINICASSETTE  C 

C  C 

c . c 

C  c 

C  CALLED  BY;  C 

C  STORE  -  STORE  DATA  IN  lEBJvlINAL'S  MINICASSETTE  C 

C  C 

C  SUBPROGPAfvlS  CALLED:  NOtffi  C 

C  c 

C  VARIABLES  USED:  C 

C  TODAY  -  TODAY'S  DATE  C 

C  EXPID  ^  EXPETJMENT  IDENTIFICATIOl  C 

C  OPEI?TR  -  OPERATOR'S  LAST  NAf-lE  C 

C  RDTE'IE  -  RECOILED  CHATCTL  READ  TIME  C 

C  CHANEL  -  CHANNEL  NtABER  C 

C  VALUE  -  SCALED  OiVTCT,  VALUE  C 

C  NCATA  -  NUMBER  CF  DATA  POINTS  TO  WRITE  ONTO  MINICASSETTE  C 

c  c 


INTEGER*2  RDTD-1E(  1175, 4)  ,aiANEL(1175)  , NDATA 
REAL*4  VALUE (1175) 

PEAL*E  TODAY, EXPID (2) , OPERTR 

C 

C . WRITE  RUN  IDENTIFICATiai 

C 

WRITE(5,1001)  EXPID ( 1) , EXPID (2) 

100 1  FORMAT  (/2X , ' EXPERIMECT :  ' ,  2A8 ) 

C 

WRITE (5, 1002)  OPERTR, TODAY 

1002  FORMAT (2X, 'OPERATOR:  ',A8,'  DATE;  ',A8) 

C 

C . WRITE  DATA  CTTIO  MINICASSETTE 


c 

WRITE (5, 1003) 

1003  FCRMAT(/2X/  H  M  S  M  C21  VALUE") 

DO  200  I=l,NnATA 

WRITE(5,1004)  (ROTL'IEd,!)  ,J=1,4)  ,CHANEL(I)  ,VALUE{I) 

1004  P0RMAT(LX,I4,2I2,I3,I2,F8.2) 

200  CCNTINUE 

C 

RBTUFN 

END 


73 


i^[^ndix  B 
Users  Manual 


Introduction 


Hie  objective  of  the  Users  Manual  is  to  provide  non-ADP  personnel 
with  the  information  necessary  to  effectively  use  the  system  (Ref  ) . 
However,  because  of  the  interactive  nature  of  the  input  requiranents  for 
the  program,  the  Users  Manual  for  the  portable  data  acquisition  software 
is  very  much  sinplified.  As  shown  in  the  next  sections,  the  Users 
Manual  is  nothing  more  than  a  list  of  suggestions  on  how  to  get  the  most 
out  of  the  system. 

Input  Formats 

Input  formats  are  made  explicit  by  system  prcnpts  and  headings.  An 
"A"  format  requires  an  alphabetic  entry;  an  "N”,  a  numeric  entry;  and 
an  "X",  an  alphabetic  or  a  numeric  entry.  Line  entries  are  titled  so 
that  required  information  nay  be  typed  underneath  the  re^ective 
heading.  For  exanple  (user  entries  are  underlined) : 


CH 

CHANNEL 

SCALE 

START  : 

READ 

TIME 

TIME 

INTERVAL 

« 

DATA  NAME 

FACTOR 

HR  MIN 

SBC 

MSEC 

HR  MIN 

SBC  r^SEC 

NN 

XXXXXXXX 

NNT'JN.NN 

NN  NN 

NN 

NNN 

NN  NN 

NN  NNN 

>  1 

CHI 

1. 

5 

>  2 

CH2 

>  3 

CH3 

>  4 

CH4 

> 
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Hiis  line  entry  results  in  (see  Appendix  C  for  more  exanples) : 


CH 

CHANNEL 

SCALE 

START  1 

READ  TIME 

TIME  : 

INTERVAL 

« 

DATA  NAME 

FACTOR 

HR  MIN 

SBC 

MSEC 

HR  MIN 

SEC 

MSEC 

1 

CHI 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

2 

CH2 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

3 

CH3 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

4 

CH4 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

Here,  one  of  the  most  powerful  features  of  the  system  is  revealed. 
After  defining  the  first  channel  fully,  the  user  need  not  do  the  same 
for  the  other  channels.  The  redundant  information  about  the  start  read 


time  and  the  time  interval  is  omitted.  By  defaulting  to  the  values  of 
the  previous  channel,  the  system  automatically  assigns  the  same  values 
to  the  channels  down  the  line.  This  automatic  default  to  the  previous 
channel's  value  occurs  only,  however,  for  values  in  an  inconplete  entry 


line. 

For  exanple: 

CH 

CHANNEL 

SCALE 

START  READ  TIME 

TIME 

INTERVAL 

« 

DATA  NAME 

FACTOR 

HR  MIN  SEC  MSEC 

HR  MIN 

SEC  ^eBC 

NN 

XXXXXXXX 

NNNN.NN 

NN  NN  NN 

NNN 

NN  NN 

NN  NNN 

>  1 

CHI 

1.0 

1  1 

500 

>  2 

CH2 

1.0 

2 

>  3 

2.0 

5 

> 

WDUld 

result  in: 

CH 

CHANNEL 

SCALE 

START  READ 

TIME 

TIME 

INTERVAL 

t 

DATA  NAME 

FACTOR 

HR  MIN  SEC 

MSEC 

HR  MIN 

SBC  MSEC 

1 

CHI 

1.00 

Oil 

0 

0  0 

0  500 

2 

CH2 

1.00 

0  0  0 

0 

0  0 

2  0 

3 

2.00 

0  0  5 

0 

0  0 

2  0 

Other  user  entries  are  not  as  ccwplicated  and,  as  already  stated, 
properly  pronpted  by  the  system.  In  addition,  the  system  echoes  all 
pertinent  input  values  to  give  the  user  a  chance  to  double-check  his 
information  before  proceeding.  For  inputs  requiring  specific  entries,  a 
list  of  possible  valid  entries  is  provided.  The  program  will  not 
procx?ed  to  the  next  executable  statement  unless  one  of  the  valid  entries 
is  received. 
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CXJtput  Format 


The  cxitput  of  the  system  is  the  collected  data  dumped  into  the 
terminal  minic:assette  tape-  Each  time  a  dump  to  the  minicassette  is 
indicated,  the  proper  run  identification  is  placed  in  front  of  the  data. 
This  run  informaticxi  includes  the  experiment  identification,  the  date, 
and  the  operator's  last  name.  The  data  is  written  in  the  format 
hhhhmmsskkknnxxxxx.xx;  where  hhhhmmsskkk  refers  to  the  time  the  data 
was  recorded  in  hours  (hhhh) ,  minutes  (mm) ,  seconds  (ss) ,  and 
milliseconds  (kkk) ;  nn  is  the  channel  number;  and  xxxxx.xx  is  the 
scaled  channel  value. 

Channel  Numbering 

Ihe  portable  data  acquisition  si^stem  accepts,  as  inputs,  both 
low-level  (millivolts  range)  and  high-level  (-lOv  to  +10v)  signals  frctn 
loboratory  ecjuipments.  The  high-level  signals  are  connected  directly  to 
the  analog- to-digital  converter.  The  low-level  signals  are  multiplexed 
and  anplified  before  they  are  fed  to  the  converter.  The  output  of  the 
amplifier  is  permanently  connected  to  channel  0  (defined  as  channel  1  in 
the  program)  of  the  converter.  Therefore,  no  high-level  signal  can  be 
defined  as  channel  1  in  the  program. 

If  there  are  more  than  one  low-level  signals,  the  channels  are 
numbered  1  to  N,  where  N  is  the  number  of  low-level  signals  to  be 
monitored.  High-level  signals,  if  present,  are  then  numbered  N-t-l  to 
N4M,  where  M  is  the  number  of  high-level  signals.  If  only  high-level 


76 


signals  are  to  be  monitored,  they  must  be  numbered  2  to  M+1. 


Channel  Naming 

Provision  was  made  in  the  program  for  the  (^ability  to  measuie 
rates  (of  change  per  unit  time) .  Ito  do  this,  the  user  sinply  uses  the 
word  "RATE"  as  the  first  four  letters  of  the  particular  channel's  data 
name.  The  value  stored  for  this  channel  is  properly  oonputed  to  d^ict 
its  change  in  value  per  second.  Heat  ip  rates  and  rate  of  crack  growth 
are  typical  measurements  being  made  in  the  Laboratory. 

General  Hints 


Scale  factors  can  be  used  to  good  advantage  by  realizing  that  the 
analog-to-digital  input  range  of  -10  volts  to  +10  volts  produces  a 
digital  conversion  of  -2048  to  2047.  The  digital  value  multiplied  by 
4.88  gives  the  signal  level  in  millivolts. 

If,  for  sane  reason  or  another,  a  need  arises  to  monitor  a  certain 
signal  with  two  channels,  the  user  is  reminded  that  it  is  perfectly 
legal  to  do  so.  Using  two  different,  judiciously  selected  scale 
factors,  one  can  monitor  actual  values  and  rates  at  the  same  time. 


^jperdix  C 
Sanple  Session 


■nie  foUcwing  "printout"  is  transcribed  froti  a  sanple  session  at  the 
operator's  terminal  after  all  the  necessary  channel  connections  between  the 
portable  data  acquisition  syston  and  the  e^^riment  equipments  have  been  made. 
The  urderlined  words  or  letters  are  user  entries.  Small  letters  enclosed  in 
parentheses  are  provided  in  soma  instances  for  clarification. 


THE  FOLLOWING  IS  A  LIST  OF  VALID  OMIANDS 

HELP  -  LIST  ALL  VALID  OOf^J^^VOS 
DEFINE  -  DEFINE  OIANNELS  TO  BE  USED 

(NORMALLY,  THE  FIRST  CCfT'AND  GIVEN) 
RUN  -  START  DATA  ACQUISITION  PROCESS 

(GIVEN  AFTER  ALL  CHANNELS  ARE  DEFINED) 
STOP  -  STOP  THE  PROGRAM 


COMMAND?  DEFINE 

(S)CHEDULE,  (D)EPENDENCY,  OR  (C)ONTRDL  FILE?  OR  (Q)UIT?  S 


CH 
« 
NN 
>  1 

aiANNEL  SCALE 

DATA  NAME  FACTOR 
XXXXXXXX  •  NNNN.NN 
CHI  1.0 

START  READ  TIME 
FIR  MIN  SEC  ^EEC 
NN  NN  NN  NNN 

TIME  INTERVAL 
HR  MIN  SEC  MSEC 
NN  NN  NN  NNN 
5 

>  2 

CH2 

>  3 

CH3 

>  4 

CH4 

>(here,  the  operator  hits  the  carriage  return  key  immediately.) 


THE  FOLLOWING  INFORM/XTION  WAS  SUPPLIED; 


CH 

CHANNEL 

SCALE 

START  : 

READ 

TIME 

TIME  : 

INTERVAL 

« 

DATA  NAME 

FACTOR 

HR 

MIN 

SEC 

MSEC 

HR  MIN 

SBC 

MSEC 

1 

CHI 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

2 

CH2 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

3 

CH3 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

4 

CH4 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

ANY  CHANGES  (Y/N) 

?  Y 

CHANGE  ALL  (CA) , 

LOCAL  (CL) 

,  ADD 

(AD) 

,  DELETE 

(DL) 

r 

OR 

(Q)UIT? 

CHANNEL?  4 


CHANNEL?  1 
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f 


CHM^JEL7  (immediate  carriage  return) 

THE  PQEIjCWING  INFOE^IATICIN  WAS  SUPPLIED; 


CH 

CHANNEL 

SCALE 

START  READ  TIME 

TIME  INTERVAL 

« 

DATA  NAME 

FACTOR 

HR  MIN  SBC  NBEC 

HR  MIN  SEC  MSEC 

3 

CH3 

1.00 

0  0  0  0 

0  0  5  0 

2 

CH2 

1.00 

0  0  0  0 

0  0  5  0 

ANY 

CHANGES  (Y/N) 

?  Y 

CHANGE  ALL  (CA) , 

LOCAL  (CL) 

,  ADD  (AD) ,  DELETE  (DL) ,  OR  (Q)UIT? 

CH 

CHANNEL 

SCALE 

START  READ  TIME 

TIME  INTERVAL 

« 

DATA  NAME 

FACTOR 

HR  MIN  SEC  MSEC 

HR  MIN  SEC  MSEC 

NN 

xxxxxxxx 

NNNN.NN 

NN  NN  NN  NNN 

NN  NN  NN  NNN 

>  2 

CH2 

1.0 

1 

100 

>(ininediate  carriage  return) 

THE 

FOLLOWING  INFORMATION  WAS  SUPPLIED: 

CH 

CHANNEL 

SCALE 

START  READ  TIME 

TIME  INTERVAL 

« 

DATA  NAME 

FACTOR 

HR  MIN  SEC  MSEC 

HR  MIN  SEC  MSEC 

3 

CH3 

1.00 

0  0  0  0 

0  0  5  0 

2 

CH2 

1.00 

0  0  10 

0  0  0  100 

ANY  CHANGES  (Y/N) 

?  Y 

CHANGE  ALL  (CA) , 

LOCAL  (CL) 

,  ADD  (AD) ,  DELETE  (DL) ,  OR  (Q)UIT?  m 

CH 

CHANNEL 

SCALE 

START  READ  TIME 

TIME  INTERVAL 

# 

DATA  NAME 

FACTOR 

HR  MLN  SEC  MSEC 

HR  MIN  SEC  MSEC 

NN 

XXXXXXXX 

NNNN.NN 

NN  NN  NN  NNN 

NN  NN  NN  NNN 

>  1 

CHI 

>(iinnediate  carriage  return) 


THE  FOLLOWING  INFORMATION  WAS  SUPPLIED: 


CH 

CHANNEL 

SCALE 

START  READ  TIME 

TIME 

INTERVAL 

* 

DATA  NAME 

FACTOR 

HR 

MIN  SEC  MSEC 

HR  MIN 

SBC  MSEC 

3 

CH3 

1.00 

0 

0  0  0 

0  0 

5  0 

2 

CH2 

1.00 

0 

0  10 

0  0 

0  100 

1 

CHI 

1.00 

0 

0  10 

0  0 

0  100 

ANY 

CHANGES  (Y/N) 

?  Y 

CHANGE  ALL  (CA) , 

LOCAL  (CL) 

,  ADD  (AD) ,  DELETE  (DL) , 

OR  (Q)UIT?  CA 

CH 

CHANNEL 

SCALE 

START  READ  TIME 

TIME 

INTERVAL 

« 

DATA  NAME 

FACTOR 

HR 

MIN  SBC  MSEC 

HR  MIN 

SEC  MSEC 

NN 

XXXXXXXX 

NNNN.NN 

NN 

NN  NN  NNN 

NN  NN 

NN  NNN 

>  1 

TEMPIA 

4.88 

1 

1  500 

>  2 

TEMPIB 

4.88 

2 

2 

>  3 

TEMP  1C 

4.88 

24 

>  4 

TEI'IPlD 

4.88 

48 

>  5 

lENGTH 

1,0 

1 

10 
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>  6  RATE _ 6.0 

>(ijntnediate  carriage  return) 

THE  FOLLOWING  INFORMATICN  WAS  SUPPLIED: 


CH 

CHANNEL 

SCALE 

START  1 

READ 

TIME  : 

INTERVAL 

1 

DATA  NAME 

FACTOR 

HR  MIN 

SBC  MSEC 

HR  MIN 

SBC 

MSEC 

1 

UMPIA 

4.88 

0 

0 

1 

0 

0 

0 

1 

500 

2 

TEMPIB 

4.88 

0 

0 

2 

0 

0 

0 

2 

0 

3 

TEMPlC 

4.88 

24 

0 

2 

0 

0 

0 

2 

0 

4 

TEMP  ID 

4.88 

48 

0 

2 

0 

0 

0 

2 

0 

5 

rSNCTH 

1.00 

0 

1 

0 

0 

0 

0 

10 

0 

6 

RATE 

6.00 

0 

1 

0 

0 

0 

0 

10 

0 

ANY  aiANGES  (Y/N) ?  N 
OOt'WAND?  DEFINE 


(S)CHEDULE,  (D) EPENDENCY,  OR  (OCWTROL  FILE?  OR  (Q)UIT?  D 


DEP 

CHANNEL 

SCALE 

IND 

OOND 

COND 

TIME  INTERVAL 

CH 

DATA  NAME 

FACTOR 

CH 

1 

VALUEl 

2 

VALUE2 

DISP 

HR  MIN  SEC  MSEC 

NN 

xxxxxxxx 

NNNN.NN 

NN 

AA 

NNNN.NN 

AA 

NNNN.NN 

AAA 

NN  NN  NN  NNN 

>  7 

TEMP2 

4.88 

1 

GT 

500.00 

LT 

525.00 

ON 

>  8 

TEMP3 

4.88 

3 

GE 

1200.00 

LE 

1212.00 

OFF 

0  0  1  500 

>(ininediate  carriage  return) 


THE  FOLLOWING  INFORMATION  WAS  SUPPLIED: 


DEP  CHANNEL 

SCALE 

IND  OOND 

CCND 

TIME 

INTERVAL 

CH  DATA  NAME 

FACTOR 

CH 

1 

VALUEl 

2 

VALUE2 

DISP 

HR  MIN 

SEC  ^EEC 

7  TEMP2 

4.88 

1 

CT 

500.00 

LT 

525.00 

ON 

8  TEMP3 

4.88 

3 

GE 

1200.00 

LE 

1212.00 

CFF 

0  0 

1  500 

ANY  CHANGES  (Y/N) ?  Y 

CHANGE  ALL  (CA) 

,  LOCAL 

(CL)  , 

ADD 

(AD) ,  DELETE 

(DL)  ,  OR 

(Q)  UIT 

'  ?  2 

ANY  CHANGES  (Y/N) ?  N 


CX»«AND?  DEFINE 


(S)CHEDULE,  (D)  EPENDENCY,  OR  (OCWTROL  FILE?  OR  (Q)UIT?  C 


CTL 

CONTROL  CHANNEL 

ACTION  IF 

OUTPUT  CH 

IF  OPERATOR 

ACTION 

RECUIRED, 

CH 

OK  IF  WITHIN 

OUT  OF  RANGE 

IF  CTL  ai 

ENTER  MESSAGE  TO  OPERATOR 

« 

VALUEl 

TO  VALUE2 

(OPER/OCTPOT) 

LOW 

HlOi 

(OPER  TYPES 

"C"  TO 

CCN^I^JUE) 

NN 

NNNN.NN 

-  NNNN.NN 

AAAAA 

NN 

NN 

AAAAAAAAAAAAAAAAAAAAAAAA 

>  4 

350.00 

360.00 

OPER 

CHANNEL  1 

OUT  OF 

RANGE! ! 

>  6 

35.00 

3 . 5 

OUTPUT' 

1 

2 

> (immediate  carriage  return) 
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*1®:  FOLLOWING  INFORMATION  WAS  SUPPLIED; 


CTL  CONTROL  CHANNEL 
CH  OK  IF  WITHIN 
I  VALUEl  TO  VMUE2 

4  350.00  360.00 

6  35.00  3.50 


ACTION  IF 
OUT  OF  RANGE 
(OPER/OUTPOT) 
QPER 

curpur 


OUTPUT  CH  IF  OPERATOR  ACTION  REQUIRED, 
IF  CTL  CH  ENTER  MESSAGE  TO  OPERATOR 
LOW  HIGH  (OPER  T!i^>ES  "C"  TO  OaiTINUE) 
CHANNEL  1  OUT  CF  RANGEU 

1  2 


ANY  CHANGES  (Y/N) ?  N 
COM4AND? 

ARE  YOU  RUNNING  RT-11?  (Y/N) . . . Y 

QHER  TODAY'S  DATE  (DDM^WYY,  20FEB81) . . . 22FEB81 

ENTER  EXPERIMENT  ID  (16  CHAR  MAXIMUM) . .  .MECHANICAL  TEST 

ENTER  OPERATOR  LAST  NAME  (8  CHAR  MAXIMUM)  . . .  IIDRETA 

ENTER  NCMBER  OF  SICHALS  TO  BE  AMPLIFIED  (MAX,  16)  :  IWUX  =  5 
IS  5  OK?  (Y/N) . . .N 

ENTER  NUMBER  OF  SIGNALS  TO  BE  AMPLIFIED  (MAX,  16) :  NUMX  =  4 
IS  4  OK?  (Y/N) , . . Y 

ENTER  NUMBER  OF  SIGNALS  THAT  NEED  NO  AMPLIFICATION  (<16-NMUX)  :  2 
IS  2  OK?  (Y/N) . . . Y 

ENTER  STOP  OPTION  (DATA  OR  TIME)  :  DATA 

ENTER  NUMBER  CF  DATA  POINTS  TO  BE  COLLEJCTED:  3000 
IS  3000  OK7  (Y/N) ...Y 


ENTER  NIJ-BER  OF  DATA  POINTS  PER  DUMP  TO  THE  MINICASSETTE  (MAX,  1100)  :  1100 
IS  1100  OK?  (Y/N)...N 


ENTER  NUMBER  CF  DATA  POINTS  PER  DUMP  TO  THE  MINICASSUTTE  (MAX,  1100)  ;  500 
IS  500  OK?  (Y/N)...Y 


***MAKE  SURE  MINICASSETTE  IS  SET  FOR  WRITINGlll 
***TUFN  THE  SYSTEM  CLOCK  ON!!! 


ENTER  'GO'  TO  START  THE  DATA  ACQUISITION  PROCESS;  GO 

As  9CX3n  as  the  operator  hits  the  return  key,  the  data  gathering  process  is 
steirted.  At  this  point,  he  may  turn  the  printer  on  his  terminal  OFF.  For 
this  particular  exanple  session,  however,  he  should  not  because  of  his 
possible  interaction  when  a  control  channel  gets  out  of  range.  Assuming  the 
e;?)erinient  runs  to  oonpletion  and  the  printer  is  ON  when  a  dunp  to  the 
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minicassette  t^)e  is  indicated,  the  following  header  and  exanple  data  may  be 
printed: 

EXPEREMENT:  MECHANICAL  TEST 
OPERATOR:  ILORBTA  DATE:  22FEB81 


H  M  S  M  CH  VALUE 
0  0  0991  1  537.52 
0  0  1991  2  323.48 
0  0  2491  1  525.74 
0  0  3991  1  520.85 
0  0  3991  2  330.95 
004  51  518.26 

004  57  152.47 
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